Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 25 Mar 2010 23:20:28 +0000
Chris Vine <chris cvine freeserve co uk> wrote:
> On Thu, 25 Mar 2010 23:45:24 +0100
> Murray Cumming <murrayc murrayc com> wrote:
> > Also, I understand the previous examples that check before
> > dereferencing, but I'm concerned that any part of my code could
> > potentially cause the TreeView to be deleted, so all my code will
> > look like this
> > 
> > if(ptr)
> >   ptr->do_something();
> > if(ptr)
> >   ptr->do_next_thing();
> > if(ptr)
> >   ptr->do_third_thing();
> > 
> > And that will be particularly awful when it forces us to declare
> > variables apart form their initialization, and make special efforts
> > to always clean up properly.
> 
> Your point is a good one if it is the case that accessing the methods
> of the TreeSelection for a non-existent TreeView does not cause the
> program to blow up (and you can live with the copious warnings that
> would no doubt be emitted were it not to cause memory faults).  I
> suppose the best test of this would be to construct a test case and
> run it under valgrind.

I can easily provoke g_critical() warnings but I have not been able to
provoke a memory fault.

I agree you would need separate 'if' blocks for, or be prepared for a
throw at, each dereference as in your example if do_something() or
do_next_thing() might delete the TreeView (although of course they
wouldn't because TreeSelections don't delete TreeViews, but you are
presumably positing that a user class derived from TreeSelection might
or there is some other intermediate code which might).

But frankly, if any of those functions might delete the TreeView, then
the program really ought to check for that rather than just hope for the
best and carry on as if all were well.

Chris