Re: gtkmm and boost

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 2007-08-14 at 19:14 +0200, Murray Cumming wrote:
> On Tue, 2007-08-14 at 12:01 -0400, Paul Davis wrote:
> > Like you mention, its always going to be a balancing act.
> > 
> > I think the thing you need to remember when thinking about changing
> > parts of the backend of Gtkmm is that it *is* a wrapper around Gtk.
> > There's no getting around that. Replacing things like Glib::RefPtr
> > with boost::shared_ptr are probably just not going to happen.
> 
> It's not entirely impossible. This suggests how to do it, though I've
> never been brave enough to make this change:
> http://bugzilla.gnome.org/show_bug.cgi?id=104332
> 
> > There will always be a whole host of issues that would simply not
> > exist if the original Gtk were written in C++. But had it been, it
> > probably would've been replaced by somethg else by now.
> 
> But we are very ambitious, so we shouldn't give up too easily.

What's the point of it, as Glib::RefPtr is a classic intrusive pointer,
and it would be trivial to replace it with boost::instrusive_ptr if that
is what is wanted?  In particular, there is usually little purpose in
trying to interface the GObject reference count with a shared_ptr class
which maintains its own reference count.

However, if that is really wanted, it would also be relatively
straightforward - all that would be required is for the constructor of
the "shared pointer" class which takes a pointer to increment the
GObject reference count to take ownership, and for the deleter function
which is called when the "shared pointer" reference count reaches 0 to
decrement it again - if no other object owns a GObject reference when
the deleter is called, the GObject will then be destroyed, otherwise
ownership will be passed to that other object.  Since boost::shared_ptr
allows custom deleter functions to be passed as an additional
constructor parameter, the latter is already provided for.  The former
(custom constructors) cannot be done, so incrementing of the GObject
reference count would have to be done by the factory function which
returns the GObject by (boost::shared_ptr) reference.

To that extent, this approach would be consisent with how functions
returning GObjects by Glib::RefPtr at present work; and the use of
custom deleters was specifically included in boost::shared_ptr to allow
factory functions of this kind to work.  I do not know if tr1 proposes a
similar interface.

Bug 104332 was concerned with the former SigC reference counting
implementation in SigC::Control_ (used by SigC::ObjectBase and
SigC::Ptr).

Chris