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 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)
> {

Ahhh. I was confused by all of the Gtk::ConstructParams business going
on. I had assumed that it was C++ style for a C constructor that would
looke something like:

gtk_adjustment_new( "lower", lower, "upper", upper, "step_increment", and so on.

> > 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',

I don't even know where these things are defined. I'd assume they're
somewhere in glibmm. And I thought gmmproc was a perl script. m4
macros... yech.

> [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.

I'm not sure I'd call this a bug, rather, it just doesn't behave in
the standard gtk way.

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

This is how all of the goocanvas demo code works. I'm 99% sure this is
the correct reasoning, but I'll post a message to the goocanvas list
to double check.

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

Thanks again,
Paul Davis