Re: [Re:[[gtkmm] technical question: GTKMM_LIFECYCLE]

[Paul Davis <pbd op net>]

>	4. If everything I said above, then I still don't understand the
>problem trying to be solved by the new memory model.
>	
>		a. Why should we care when the container destructs if we are
>maintaining references to the contained objects. We can simply connect to the
>"destroy" signal handler of the container and iterate over our "list" of
>objects and destroy/de-reference them.

there are 2 objects in question:

      * the underlying C object
      * the C++ wrapper object

the goal is to have sane, useful, workable integration of both their
lifecycles. for example, you don't want the C object to vanish without
the C++ object also vanishing (gtkmm ensures that this works OK). 

the problem here is entirely caused (IMHO) by the fact that at the C
level, GTK doesn't use reference counting to manages widgets placed in
containers. when the container is destroyed, the container doesn't
unref the widget, it destroys it.

this is unintuitive behaviour (like quite a bit of GTK+, alas), and
conflicts with the model adopted by the gstreamer people. both use the
underling GObject code, but gstreamer's containers use ref and unref
to manage objects placed within them - they never explicitly destroy
an object when a container is destroyed.

does that make it any clearer? 

--p