[bt-devel] Programming Techniques

[Joachim Ansorg]

Hi Dave!
> CStyleEditorDlg* dlg = new CStyleEditorDialog(style,this);
> dlg->exec();
> delete dlg;
>
> It should instead read:
>
> CStyleEditorDlg dlg(style,this);
> dlg.exec();

Fixed now.

> (Exception: Some gui libraries require that certain objects be allocated
> on the heap. This is not common, but if it is the case with Qt then this
> would be an exception)

All QWidgets delete their child widgets at destruction time. So the child 
child widgets should be created on the heap.

> > 	CSwordKey* key = CSwordKey::createInstance(module);
> > Is there a way to do this on the stack?
>
> No, because Sword (apparently) creates it on the heap inside
> CSwordKey::createInstance and then returns the key to you. I am assuming
> that the reason Sword does this, rather then return the object by value,
> and avoid dynamic allocation is that these key objects exhibit
> polymorphic behaviour.

The backend/* classes are BibleTime's own classes. We reimplemented some 
things to be use Sword's classes in a more simple way.

> In this case, this is where my scoped_resource stuff comes in. However,
> I'm not sure if the way Sword does this is the best way to do it. I
> would have tended to think that keys should be concrete types, but not
> knowing the design decisions etc I can't really comment. So of course,
> you would change that code to:

Since the backend/ classes are our own ones we can still discuss on design 
decissions :)

> I assume CSwordVerseKey is a class (directly or indirectly) derived from
> CSwordKey. Now, firstly the key class hierarchy should do its best to
> use polymorphism so that you don't have to get a pointer to the derived
> class. If you do have to get a pointer to the derived class, in my
> opinion that is a sign of a potential design flaw in the CSwordKey
> hierarchy.

I'd suggest to dicuss abut our class structure after 1.1 is released.

> > One last question: How do we manage things if the deklaration of a member
> > is in the header file and the new statement is in the .cpp file? For
> > example CHTMLWidget::m_toolTip.
> > Help is appreciated :)

> A resource that is a class member, and is released in the destructor of
> the class, is not nearly so much a problem as objects that are acquired
> and then released within a single scope. This is because the language
> guarantees calling of the class's destructor, and if an exception is
> thrown in a destructor, you have far too many problems to start worrying
> about resources not being released :)
>
> However, I may add a more flexible resource management wrapper,
> smart_resource, which uses reference counting to allow it to offer
> copying, and hence be used in more situations.

Thanks for your help!

Joachim