After digging a bit into standards, I found following :
Here, I am trying to initialize vector<char>
using two string literals, not two chars.
using vector(initializer_list<T>)
. In this case, vector(initializer_list<char>)
.
But the type of a string literal is "array of n const char", so the initializer-list constructor is not a match.
This doesn't result in compiler error, since the compiler is able to find another constructor that matches
§13.3.1.7¶1 explains the rules :
"When objects of
non-aggregate class type T are list-initialized, overload resolution
selects the constructor in two phases:
— Initially, the candidate
functions are the initializer-list constructors of the class T and the
argument list consists of the initializer list as a single argument
[which we have seen didn't match].
— If no viable initializer-list
constructor is found, overload resolution is performed again, where
the candidate functions are all the constructors of the class T and
the argument list consists of the elements of the initializer list."
And the match in this case is :
template <class InputIterator> vector(InputIterator first, InputIterator last)
The type of InputIterator
has no info of T
in the vector<T>
.
So even if I'm initializing a vector<char>
, the two arguments can be of arbitrary type.
The only requirement is that they stick to InputIterator
property, which const char[]
happens to do.
The constructor believes it has been passed two iterators to the same sequence,
but it has actually been passed iterators to two completely different sequences, "y"
and "z"
.
So the result of this program is undefined .
Thanks to chris's comment
This is post is exactly same as he mentioned over there. See this