Re: gtkmm 3.0: Removing ListHandle, SListHandle, etc

[Guillaume Brocker <guillaume brocker digital-trainers com>]

I solved a similar question by making the return type of such methods 
template. The effective container type choice is left to the caller, so 
he can use what's most useful for him. You don't have to rewrite the 
code for each container type you want to support. The only prerequisite 
was the container type have to be a model of back insertion sequence so 
I was able to write generic code for inserting items in the collections.

Le 18/05/2010 21:41, Murray Cumming a écrit :
> In gtkmm 3.0, I'd like to remove the intermediate container types
> because they just confuse people and make it necessary to read the
> documentation:
> http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-intermediate-types.html.en
>
> So, for instance, Gtk::FileChooser::get_uris() would return a
> std::list<>  or std::vector instead of a Glib::SListhandle<>:
> http://library.gnome.org/devel/gtkmm/2.20/classGtk_1_1FileChooser.html#abe7450acc71c70b5f595f9e23224a24e
>
> I think people generally agree with me about this, but I'd like to hear
> about any objections.
>
> Also, should we use std::list or std::vector? I suspect that std::vector
> would be more useful.