Re: Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ?

[Daniel Boles <dboles src gmail com>]

On 10 March 2017 at 14:58, Kjell Ahlstedt <kjell ahlstedt bredband net> wrote:

I don't think it has been considered, and certainly not rejected. It's a good idea.

Cool!

 

A lot of details can be discussed. There could be

Gtk::Container::add(std::initializer_list<Gtk::Widget*> widgets);
Gtk::Box::pack_start(std::initializer_list<Gtk::Widget*> widgets, PackOptions options);
Gtk::Box::pack_end(std::initializer_list<Gtk::Widget*> widgets, PackOptions options);
etc.

Indeed. I just didn't want to suggest too many variations at first, in case even the most basic ones weren't an option. :D

 

It would be even better with a list of references: std::initializer_list<Gtk::Widget&>. Is that possible, or would the compiler try to copy the widgets?

Containers of references aren't possible in C++. The closest thing to this, I guess, is std::reference_wrapper<Gtk::Widget> - i.e. a utility class that wraps a pointer and gives it reference-like semantics (plus a few extras).

This might (I dunno) mean some extra boilerplate or compromise, but it would probably be worth it to ensure none of the passed elements are nullptr. So, that's a good point. We might want to guard against that. Alternatively, we could just tell users that passing a nullptr is UB and trust them to do it right. I guess this is one to debate.

Even then, yes, initializer_list is still restricted to having implicitly const elements, so the reference_wrappers would be copied, but again, since they too are just pointers really, that's fine. (but IMO movable-from initializer_lists are sorely needed for other cases, though)