Re: Some feedback about using gtkmm in real projects.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 12 Feb 2009 17:43:19 +0000
Chris Vine <chris cvine freeserve co uk> wrote:
[snip]
> Since objects derived from Gtk::Widget are not intended to be copied
> (see more below), it would be pointless to obtain them by factory
> function.  They can be constructed as auto objects (on the stack)
> or with operator new on the heap in the ordinary way, and would
> normally be managed by their container.
> 
> It is therefore not an implementation detail as suggested by Germán,
> but deliberate policy.  It is also something the user doesn't need to
> puzzle over and frankly should not get in his way.  If an object can
> only be obtained via a factory function returning it by Glib::RefPtr,
> then use Glib::RefPtr; if it doesn't, then don't.  The mistake is in
> thinking that Glib::RefPtr is a generic smart pointer.

On further thought about this, what I have said is true so far as
concerns using Glib::RefPtr to manage objects derived from Gtk::Widget
(it does not seem to me to be a good idea).

However, Germán's point does raise the issue why pure GObject objects
are always created in gtkmm by factory functions, rather than being
created as auto objects or by the new expression as in the case of
objects derived from GInitiallyUnowned/GtkObject.   The fact that pure
GObjects have no floating reference on creation is not crucial to the
issue of how they are to be implemented in glibmm/gtkmm.

Is there any special reason why pure GObject objects are always
managed by smart pointer in gtkmm?

Chris