On Sun, 2010-03-28 at 14:07 +0100, Chris Vine wrote: > On Thu, 25 Mar 2010 23:20:28 +0000 > Chris Vine <[email protected]> wrote: > > On Thu, 25 Mar 2010 23:45:24 +0100 > > Murray Cumming <[email protected]> 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.
Actually, we probably need to find a better example. I think it's generally agreed that there's no reason for TreeSelection to be a separate class from TreeView. -- [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
