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

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;
>  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
That's all for now, I hope I didn't tell too much rubbish...

Bye bye,

>                                       Guillaume.
>To unsubscribe: mail -s unsubscribe < /dev/null

E-Mail: Oliver Freyd <>
Date: 06-Aug-98
Time: 22:48:18

This message was sent by XFMail

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]