Re: gtkmm 3.0.

[Paul Davis <paul linuxaudiosystems com>]

On Sun, Mar 28, 2010 at 9:07 AM, Chris Vine <chris cvine freeserve co uk> wrote:
> 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.

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