Any thoughts on this C++ smart pointer issue?

[Brian J. Tarricone]

Jeff Franks wrote:

> Brian (and other C++ enthusiast's),
>
> There is one smart pointer issue that may come up when you see the 
> first XFC development tarballs, so I thought I'd seek your preference 
> now, if any.

[snip: info about smart pointer usage]

> My only concern with this approach is that the smart pointer is 
> template class with some small overhead. The more you use smart 
> pointers the bigger the overhead. Optimally, managing reference 
> counting yourself is better but not as convenient, and there are times 
> when this was preferred. So far I have taken the view that the 
> programmer should have the choice. An experienced GTK+ programmer 
> should feel quite comfortable calling ref() and unref() on an object. 
> Whereas a new programmer that isn't sure can just use a smart pointer.

i like choice.  choice is good.  it's always nice to have choice.  
having said that, i feel like one of the bonuses/benefits of using a c++ 
wrapper like Gtkmm or XFC is that a good number of the annoyances with 
gtk's C-based OO API disappear, one of those being refcount management 
(for objects like in this case).  i tend to think that, a programmer, 
when choosing something like gtkmm or XFC, will implicitly agree to the 
premise that they're getting a better abstraction and a toolset that's a 
little easier to work with, at the expense of some amount of performance 
(and/or memory usage?).

personally, i would just use the smart pointers all the time, unless i 
later find that i can greatly enhance performance in portions of my code 
by not doing so.  premature optimisation is the root of all (most) evil.

so my feeling is that it's great to have that choice there, but i think 
that the use of "the old way" should be discouraged (in the same sense 
that accessing the raw C GObject pointer in gtkmm is discouraged).

that's just how i feel about it; jeff, it's your show, and you know the 
implementation details, so it's of course ultimately up to you.

> Compared with Gtkmm, you can create and use a Xfc::Gtk::AccelGroup 
> either like this:
>
> Pointer<Gtk::AccelGroup> accel_group = new Gtk::AccelGroup;
> // use accel_group, it is unreferenced when it goes out of scope
>
> or like this:
>
> Gtk::AccelGroup *accel_group = new Gtk::AccelGroup;
> // use accel_group
> accel_group->unref();

ok, i'm slightly confused now.  for the first example, is that correct, 
or should it be "= Gtk::AccelGroup::create();"?

> The only disadvantage with this approach is that it requires the 
> programmer to be aware of the class a new object derives from: 
> Xfc::G::Object (never floating) or Xfc::Gtk::Object (floating). All 
> the reference counting rules are identical to GTK+. So if you pass a 
> floating object to an owner, or add a widget to a container, you don't 
> need to worry about reference counting or smart pointers. If you pass 
> a G::Object to an owner, like a Gtk::AccelGroup to a window, you have 
> to explicitly unreference it after if you are not using a smart 
> pointer. This only applies to object construction. All class methods 
> that return a pointer to an object that must be unreferenced return as 
> a smart pointer.

i think this is fine.  i think most gtk programmers that have dealt with 
these issues already know how gtk's floating references work, and that 
they're unique to classes that inherit from GtkObject.  so as long as 
the semantics are the same as the C interface (as you point out), i 
think we're ok here.  the win here is that new XFC programmers don't 
have to learn any new semantics if they don't want to: they can just 
continue to do things in the same way as when they used the C APIs.  
actually, this is another argument for keeping the choice of smart 
pointer vs. manual memory management.  of course, prominently advocating 
the use of the smart-pointer interface in the API docs is a must, IMO.

good to hear more about this, jeff; i'm looking forward to playing with 
XFC at some point ^_^.

    -brian