Re: help on array of widgets

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 27 Jul 2011 13:30:48 +0200
Yann Leydier <yann leydier info> wrote:
> It is the exact opposite ! :o)
> 
> std::vector<Gtk::Button*> buttons;
> buttons.push_back(Gtk::manage(new Gtk::Button("but")));
> vbox.pack_start(*buttons.back(), …
> 
> Calling Gtk::manage(widget_pointer) will cause the widget to be freed 
> when its parent is destroyed.
> 
> Glib::RefPtr is generally not to be used when the API does not force
> you to use it.

On the last point, more accurately Glib::RefPtr is not intended to be
used with objects whose contained C object derives from
GInitiallyUnowned, which in gtkmm terms means anything deriving from
Gtk::Widget. Gtk::Widgets are not managed by RefPtr but are instead
intended either to be constructed without the new expression (say, as a
member of another class) or, if constructed by the new expression, then
to be managed by their container via Gtk::manage.

Given their intended purpose, there is very rarely a good reason to put
a gtkmm widget in a standard C++ container (I was going to say that
there is no good reason but that may be going too far), and they cannot
be contained by value because they are not copy constructible or copy
assignable (for very good reason). If there were to be an exceptional
reason why they must be held in a vector, as you say it would be best
for them to be held by raw pointer, but in that case I would strongly
advise against calling Gtk::manage() on them as you suggest, as that
could leave the std::vector container holding a pointer to an invalid
object - its lifetime would be controlled by the gtkmm container in
which it happens to be contained, which would negate the (imagined)
purpose of putting it in a vector in the first place.  It is completely
pointless putting a managed object in an aggregate C++ container.

Probably the original poster needs to explain what purpose he is trying
to achieve in storing widgets in a vector. There is probably a
fundamental design error present.

Chris