Re: Wrapping C constructors.

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
dnl If necessary, _CONSTRUCT_SPECIFIC(BaseClass, Class) must be used

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.

> 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

Thanks again,
Paul Davis

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