Wt

So any time I instantiate a widget with new and then call addWidget or addItem or assign the parent argument somewhere, then cleanup is guaranteed, because it acquires a parent and becomes part of the widget tree, correct?

What I am a bit confused about is that in most frameworks there is a distinction between parent with respect to memory management and parent with respect to display - I believe I have also found that in Wt - certain widgets require a parent for memory management but their display is managed by a different widget. I suppose that if I just abide by what Wt's functions require - be it for display or for memory management - things will be OK.

Another question I have is that I prefer not to use pointers except when the design mandates it - Stroustrup's RAII. But Wt is built entirely on pointers, which I consider a drawback (But I still love Wt...). I assume that instantiating widgets on the stack and using &Widget in Wt functions would not work out very well.... (I could probably prove that quickly it with some simple tests.)

This strategy means that you usually don't have to write delete in a Wt application.

However if I instantiate my own objects with new, I assume the normal rules of C memory management apply...

Tnx

MNG

Mikey Nosihcan wrote:

So any time I instantiate a widget with new and then call addWidget or addItem or assign the parent argument somewhere, then cleanup is guaranteed, because it acquires a parent and becomes part of the widget tree, correct?

>

correct

What I am a bit confused about is that in most frameworks there is a distinction between parent with respect to memory management and parent with respect to display - I believe I have also found that in Wt - certain widgets require a parent for memory management but their display is managed by a different widget. I suppose that if I just abide by what Wt's functions require - be it for display or for memory management - things will be OK.

>

The two are indeed kind of two different things, but it feels quite natural to keep widget parent-child relations identical do memory management parent-child releations. Wt is not the only framework that does this. So indeed, if a widget is added to a parent in the widget tree, the parent also becomes its memory management parent.

Another question I have is that I prefer not to use pointers except when the design mandates it - Stroustrup's RAII. But Wt is built entirely on pointers, which I consider a drawback (But I still love Wt...). I assume that instantiating widgets on the stack and using &Widget in Wt functions would not work out very well.... (I could probably prove that quickly it with some simple tests.)

>

I believe that the equivalent or RAII would be to instantiate child widgets by value in a parent class. I know some people use this strategy when making a Wt application, but you'll notice that it has practical drawbacks too, e.g. you need to include the full header file of all child widgets iso being able to use forward declarations.

This strategy means that you usually don't have to write delete in a Wt application.

However if I instantiate my own objects with new, I assume the normal rules of C memory management apply...

>

Of course. Only classes that inherit from WObject follow these rules (but you still can delete WObjects with delete too, without problems).

Wim.

OK - excellent - thanks for the info.

MNG