Re: Wrapping C constructors.

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

On 5/21/07, Murray Cumming <murrayc murrayc com> wrote:
> On Mon, 2007-05-21 at 03:11 -0500, Paul Davis 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.
>
> You should almost never do this. You should use the _CONSTRUCT macro, so
> that g_object_new() is used in the generated source code.

Is there an example of using _CONSTRUCT to with new functions of the form:

goo_canvas_rect_new( GooCanvasItem* parent, int x, int y, int width,
int height, ...)

All the _CONSTRUCT things I saw didn't have named parameters. Which I
would take to mean the new functions would roughly translate to:

goo_canvas_rect_new( ... )

There's also the _CONSTRUCT_SPECIFIC macro. What does that do? And
when do I use either?

> >  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.
>
> A starting refcount of 2 would not be very useful. That would just leak
> a reference when the RefPtr was destroyed.
>
> > 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.
>
> That doesn't make any sense to me. A new() function would not destroy
> the object before returning it.

It don't.  Each goocanvas object is added automatically to its parent
object. Adding an object to a parent object causes the ref_count to be
incremented (making the ref_count = 2 ) then the new() function unrefs
it (making it 1 again).

Two pieces of pseudocode:

//What goocanvas trys to avoid:
void
foo(GooCanvasItem* parent)
{
  GooCanvasItem* group = goo_canvas_group_new( parent,NULL) ;
 g_object_unref(group) ;
}

//Actually using goocanvas:
void
foo(GooCanvasItem* parent)
{
 GooCanvasItem* group =goo_canvas_group_new(parent,NULL);
}

You see, in the first example, if Goocanvas didn't unref each object,
the application coder would have to. Fairly silly and I understand why
they would do such a thing.

In C++, I create a RefPtr that destroys the object (if I don't add the
reference() call to the constructor) when its destroyed. Hence the
following:

void
foo( const Glib::RefPtr<Goocanvas::Item>& parent)
{
 Glib::RefPtr<Goocanvas::Item> group = Goocanvas::Group::create(parent) ;
} //group goes out of scope, underyling C-instance would be destroyed
(without extra reference() call)

cause a segfault because 'parent' thinks it has a child, but it was destroyed.

> > 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.
>
> If you can please mention some specific part of the API, I could take a
> look.

Any _new() function does this as far as I know.

Specifically, goo_canvas_group_new() has an unref in it.
goocanvasgroup.c line 111.

> > 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
>
> --
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com