Re: Some feedback about using gtkmm in real projects.

[Germán Diago <germandiago gmail com>]

Sorry for the previous message. It was a mistake.


> Possibly the rationale behind Glib::RefPtr could be explained a bit
> more in the documentation.

I don't really mind the internal implementation of Gtk+ objects. It
should be a way
to construct any object uniformly, that's the point of using an
interface. The point,
I think, is to do it C++-ish and not to use strange things.
 I don't know very well
if it can be achieved, because I don't know gtk+ internals very well,
but I think that
if there's a reasonable way to make uniform object creation, it should
be done, whatever
gtk+ does internally. In Python, C# and Vala or whatever bindings I know of,
objects are all created the same way. I know
they use the heap and have garbage colletion and so on in the
mentioned languages.
But as an interface, the implementation should be uniformized as much
as possible (in my opinion)
and adapted to the language.
And Glib::RefPtrs can get in the way many times. They don't have
operator*, which I needed more than
once. But you cannot use operator-> in some contexts. For example,
when you want to pass a reference
to the object.

> Move constructors are constructors which can take an r value by
> non-const reference (they are declared as T::T(T&&)). They are intended
> to improve efficiency by enabling you to code a constructor which will
> avoid an unnecessary copy when being initialised by a temporary.  They
> invalidate the movee (which obviously doesn't matter for a temporary),
> hence the "move" in the name.
>
> Since objects derived from Gtk::Widget are not intended to be copied,
> either through a copy constructor or an assignment operator, it would
> probably help if Germán could explain his proposal further.  It may be
> he was thinking of something different.

Move constructors are a good way to be able to:

1.- Put widgets in containers.
2.- Return by value efficiently.

These are two good properties in general c++ style of programming. You
don't need to use heap allocation if you can
return a widget from a function. And you can use containers to store
objects. Maybe number 2) is more useful
for gtk+, who knows.