Re: Wrapping C constructors.

[Murray Cumming <murrayc murrayc com>]

On Mon, 2007-05-21 at 04:30 -0500, Paul Davis wrote:
> 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, ...)

Yes. Here is the first such one that regexxer found for me in gtkmm:

Adjustment::Adjustment(double value, double lower, double upper, double
step_increment, double page_increment, double page_size)
:
  _CONSTRUCT("lower", lower, "upper", upper, "step_increment",
step_increment, "page_increment", page_increment, "page_size",
page_size, "value", value)
{

> 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?

Yes, this should be documented, but regexxer showed me the .m4
defintion, which has a comment:

dnl _CONSTRUCT() does not deal with multiple class definitions in one
file.
dnl If necessary, _CONSTRUCT_SPECIFIC(BaseClass, Class) must be used
instead.
dnl
m4_define(`_CONSTRUCT_SPECIFIC',

[snip]
> 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).

OK. That is quite unusual, and seems like a bug in goocanvas to me,
because its inconsistent with other GTK+ functions. A _new() function
usually returns a reference and requires a g_object_unref() later.
GtkWidgets don't, but they use their own "floating" reference idea.

After checking that this is really what goocanvas wants to do, you might
need to add the reference, as you suggest.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com