You can use a variadic template constructor instead of an initializer list constructor: struct foo { int x[2]; template <typename… T> foo(T… ts) : x{ts…} { // note the use of brace-init-list } }; int main() { foo f1(1,2); // OK foo f2{1,2}; // Also OK foo f3(42); // OK; x[1] zero-initialized foo f4(1,2,3); // … Read more
The standard committee seems to intend on initializer_list being a literal type. However, it doesn’t look like it’s an explicit requirement, and seems to be a bug in the standard. From § 3.9.10.5: A type is a literal type if it is: – a class type (Clause 9) that has all of the following properties: … Read more
This appears to be a parsing ambuguity somewhat similar to the famous most vexing parse. I suspect what’s going on is that: If you write std::array<std::pair<int, int>, 3> b {{1, 11}, {2, 22}, {3, 33}}; the compiler has two ways to interpret the syntax: You perform a full-brace initialization (meaning the outermost brace refers to … Read more
Introduction Imagine the following declaration, and usage: struct A { A (std::initializer_list<std::string>); }; A {{“a” }}; // (A), initialization of 1 string A {{“a”, “b” }}; // (B), initialization of 1 string << !! A {{“a”, “b”, “c”}}; // (C), initialization of 3 strings In (A) and (C), each c-style string is causing the initialization … Read more
The answer is NO, you cannot do that. An object of type std::initializer_list<T> is a lightweight proxy object that provides access to an array of objects of type T. A std::initializer_list object is automatically constructed when: a braced-init-list is used in list-initialization, including function-call list initialization and assignment expressions (not to be confused with constructor … Read more
They are not the same if member1 and member2 are non-POD (i.e. non-Plain Old Data) types: public : Thing(int _foo, int _bar){ member1 = _foo; member2 = _bar; } is equivalent to public : Thing(int _foo, int _bar) : member1(), member2(){ member1 = _foo; member2 = _bar; } because they will be initialized before the … Read more
It exists and works well: std::map <int, std::string> x { std::make_pair (42, “foo”), std::make_pair (3, “bar”) }; Remember that value type of a map is pair <const key_type, mapped_type>, so you basically need a list of pairs with of the same or convertible types. With unified initialization with std::pair, the code becomes even simpler std::map … Read more
There were already examples of “core” language features that returned types defined in the std namespace. typeid returns std::type_info and (stretching a point perhaps) sizeof returns std::size_t. In the former case, you already need to include a standard header in order to use this so-called “core language” feature. Now, for initializer lists it happens that … Read more
I think the following could be a good guideline: If the (single) value you are initializing with is intended to be the exact value of the object, use copy (=) initialization (because then in case of error, you’ll never accidentally invoke an explicit constructor, which generally interprets the provided value differently). In places where copy … Read more
No, that won’t work as intended; you will still get copies. I’m pretty surprised by this, as I’d thought that initializer_list existed to keep an array of temporaries until they were move‘d. begin and end for initializer_list return const T *, so the result of move in your code is T const && — an … Read more