Re: Wrapping C constructors.

["Paul Davis" <pjdavis engineering uiowa edu>]

On 5/21/07, Paul Davis <pjdavis engineering uiowa edu> wrote:
> Hey,
>
> I went through and changed how I was doing all of the create methods
> for Goocanvas. I was having issues with a constructor and I seemed to
> remember Murray saying that I should hand-code constructors as opposed
> to hand-coding static create methods. Which makes quite a bit of sense
> if we want the ability to subclass the goocanvas objects.
>
> The issue at hand is this: after calling any of the goocanvas new
> methods (ie, goo_canvas_rect_new(...)) we get an object that has a
> ref_count of 1. This result will almost always be put into a
> Glib::RefPtr. After the object is in the RefPtr, I would expect it to
> have a ref_count of two. Instead, they have a ref_count of 1.
>
> Some looking through the api has lead me to find that goocanvas always
> does an unref in the new function. I'm under the impression that this
> is to save C coders from calling unref on every object they create.
>
> In C++ land this presents a predicament. We have the one new object
> being referred to in two places (as a child of the parent object and
> from the Glib::RefPtr) and when the RefPtr goes out of scope the
> object gets destroyed. This leads to segfaults and other nasty errors.
>
> Looking through gtkmm source, I can't find an example like this. So
> almost every constructor has to be hand coded to be something along
> the lines of:
>
> Group::Group( const Glib::RefPtr<Goocanvas::Item>& parent )
>   :
>     ItemSimple( GOO_CANVAS_ITEM_SIMPLE(goo_canvas_group_new(
> parent->gobj(), NULL ) ) )
> {
>   reference() ; //This is the un-good bit.
> }
>
> That seems un-good. Is there a 'gmmproc' way to autogenerate this
> extra reference, or is this just a side effect of the way goocanvas is
> written?
>
> ----
>
> In other news, I've gotten the simple demo, a custom demo, and most of
> the first notebook page of the 'main' demo written and working. Things
> are coming along.
>
> Paul Davis

Just noticed I'm getting this error on some of the objects I
hand-coded constructors for:

(lt-moving_shapes:22248): glibmm-WARNING **: This object, of type
GooCanvasRectModel, already has a wrapper.
You should use wrap() instead of a constructor.

I've spent a bit trying to trace down what would cause this. As far as
I can tell would be from trying to pass the same gobject pointer to
two gtkmm constructors.

The weird part is that this appears to only happen for GooCanvas*Model
objects. Normal GooCanvas* objects don't cause this warning to be
printed. Looking at the inheritance hierarchy I can't see a difference
that appears related.

Paul Davis