I assume, with your examples for std::vector<int> and std::string you meant to also cover the other containers, e.g., std::list<int>, std::deque<int>, etc. which have the same problem, obviously, as std::vector<int>. Likewise, the int isn’t the only type as it also applies to char, short, long and their unsigned version (possibly a few other integral types, too). … Read more
As pointed out by Nicol Bolas, the original version of this answer was incorrect: cppreference at the time of writing incorrectly documented the order in which constructors were considered in list-initialization. Below is an answer using the rules as they exist in the n4140 draft of the standard, which is very close to the official … Read more
Short version Initialization via {..} is list-initialization, which prohibits narrowing conversions. For example, if LLONG_MAX is the maximum value of an long long int, and your int cannot represent that: int x = LLONG_MAX; // probably accepted with a warning int x {LLONG_MAX}; // error Similarly: long long y = /*something*/; int x = y; … 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
It’s specifically because you use an initializer list that the copy-constructor is used. The initializer list is initialized with a copy of the object, and then passed to the vector. If you read the linked reference, from C++14 it even explicitly say … each element is copy-initialized … from the corresponding element of the original … Read more
The warning is indicating that regardless of the order you use in the constructor initialization list the standard requires that non-static data members be initialized in the order they were declared. We can see this by going to the draft C++ standard section 12.6.2 Initializing bases and members paragraph 10 which says: In a non-delegating … Read more
You are guessing correctly. std::initializer_list elements are always const (which makes sort()ing them impossible, as sort() is a non-const member function) and its elements are always copied (which would make sort()-ing them meaningless even if they weren’t const). From [dcl.init.list], emphasis mine: An object of type std::initializer_list<E> is constructed from an initializer list as if … Read more
Yes, its a bug. This is something new and was voted in the working paper in February 2012 (link). Nicol Bolas makes a good point in that gcc is actually the conforming compiler according to the FDIS approved C++11 standard because the changes to the working paper were made after that.
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
The initializer_list behavior is buggy. In its destructor it calls a vector delete (a delete[]) of the entire range and then deletes the first entry in the array again. This behavior is not part of the initializer_list class and looks like a compiler bug. initializer_list doesn’t have a destructor and doesn’t allocate the array used … Read more