On Sun, Mar 28, 2010 at 9:07 AM, Chris Vine <[email protected]> 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.
isn't this *precisely* why you use refcounted strong&weak references? if ptr was a strong reference to the treeview, it *could not* be deleted during ptr's scope. otoh, i am sure you know this murray, so i'm probably missing the point of your example ... --p _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
