Re: gtk--: segfault in destructor of spinbutton!

[Oliver Freyd <freyd uni-muenster de>]

Thanks for this long answer.

>It's a bug all right. We're deleting something we have no idea if we
>actually can. Also, the get_adjustment() method will crash too.
> 
>>Only I have no idea how to find out if an object
>> was created by "new" or just on the stack.
>
>You can't, AFAIK. (writing our own operator new perhaps ?)
> 
I think you're right here, and if it would be possible a different
behavior for stack or heap object would be confusing.

>> Maybe someone else knows more, or should I better create everything
>> with new and delete it in the destructor. But then how do I know if
>> a container will delete what it contains or if I should do it
>> myself?
>
>This is precisely the problem Tero and I have been trying to tackle
>(see the Gtk_SpinButton::get_adjustment() method for a scheme of the
>solution): How to handle methods which return pointers to newly
>created objects... You've just proved we've been a bit overzealous.
>
>- We could be leaving it to the user to delete whatever needs to be
>deleted. Since the Gtk_Adjustment can be passed as an argument to the
>constructor, or set later on, there's no way we can know for sure if
>the adjustment member (adjustment_widget) points to something we can
>(or should) delete.

If I look at the source, I see that in the constructor and the set_adjustment
method a pointer is passed, so I'd say the object belongs to the user,
either as static object or created be new and to be deleted in a destructor.
The only problem is with the castitem constructor, where the c object
is given and there is no c++ object. So maybe one should create (new)
a Gtk_Adjustment there that corresponds to the c object. A flag could
tell the destructor to delete it, but not the usual Gtk_Adjustment.
Also in set_adjustment this "owned" Adjustment should be killed
before changing the pointer to the new one.



>OTOH, this means that calling get_adjustment() means you have to
>delete the result. Not very consistent with the gtk API, this is
>supposed to be a simple accessor.
>
That would'n be so nice, I think people will forget it and get memory leaks...


>- Or, we could overload both set_adjustment() and the constructor to
>take Gtk_Adjustment&, and those would set some internal flag which
>would tell the destructor and get_adjustment() to leave the adjustment
>member alone ?
>
What is the real difference between Gtk_Adjustment* and Gtk_Adjustment& ?
I mean references are pointers internally...

>Like this :
>
>Gtk_SpinButton::Gtk_SpinButton(Gtk_Adjustment &adjustment,
>                              gfloat climb_rate, gint digits) :
>  Gtk_Entry(GTK_ENTRY(gtk_type_new(c_class.get_type()))),
>  adjustment_widget(&adjustment)
>{
>  gtk_spin_button_construct(gtkobj(),
>                           adjustment.gtkobj(),
>                           climb_rate, digits);
>  m_delete_adjustment = false;
>}
>
>[...]
>
>Gtk_SpinButton::~Gtk_SpinButton()
>{
>  if(adjustment_widget && m_delete_adjustment) delete adjustment_widget;
>}
>
>This means the only thing the user has to take care of is not to pass
>the address of a stack object to the constructor or set_adjustment(),
>but that's a much lighter burden than deleting the result of a trivial
>accessor IMHO.
>
>- Finally, may be the simplest solution would be not to delete anything,
>but have get_adjustment() be a simple accessor indeed, and simply
>return adjustment_widget, instead of calling
>gtk_spin_button_get_adjustment() and wrapping a new Gtk_Adjustment
>around the result. adjustment_widget would of course be maintained by
>the constructor and set_adjustment().
>
Yeah, I think that's the best, the only thing that remains would be 
the castitem constructor, and this would be rarely used (only my opinion...)

>I prefer the third and last solution, unless some of you have better
>suggestions.
>
That's all for now, I hope I didn't tell too much rubbish...

Bye bye,
      Oliver


>-- 
>                                       Guillaume.
>                                       http://www.worldnet.fr/~glaurent
>
>-- 
>To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>

----------------------------------
E-Mail: Oliver Freyd <freyd@uni-muenster.de>
Date: 06-Aug-98
Time: 22:48:18

This message was sent by XFMail
----------------------------------