为什么第二次初始化工作而第一个由于“元素类型不匹配”而失败？

Question

In c++ primer-initializing a Container as a copy of another container.

The element types in the new and original containers can differ as long as it is possible to convert the elements we are copying to the element type of the container we are initializing.

For example:

vector<const char*> articles = {"a", "an", "the"};
vector<string> words(articles) ; //error:element types must match
forward_list<string> words(articles.begin(), articles.end()); // ok, convert const char* to string

My question is why the second initialization work while the first one fail because of the element type does not match ?

Answer 1

The first line calls the constructor with an initializer_list of the same type as the element type ( const char*). something like this:

vector<T>(initializer_list<T> t ) {....} 

--> OK!

The second is a copy-constructor call which is only defined for the same element type.

vector<T>(const& vector<T> t) {...}

What you did is something like this:

vector<string>(const& vector<const char*> t){..}

--> Which does not exist!

Answer 2

First line performs copy-list-initialization (cfr. initializer_list constructor ).

Second line has no matching constructor since the types don't match (it can't call a copy constructor).

Third line instead uses the iterator range constructor which emplace-constructs elements and has a viable const char* to string conversion to use.

Answer 3

My question is why the second initialization works while the first one fails

You're constructing a something . This isn't done by magic, it just has to call one of the something 's constructors. Any expression which can't match one of the constructors, can't compile.

---

So, let's first consider

vector<const char*> articles = {"a", "an", "the"};
vector<string> words(articles);

Now, we need some std::vector constructor that makes sense with this expression. They're listed here , and the only ones that come close to matching are numbers 5 and 6 (at the time of writing - they're the copy and move constructors).

The move constructor is out because we're not using std::move or otherwise working directly on an rvalue reference, so let's take a look at the copy constructor:

vector<string>::vector<string>(const vector<string> &other);

Note that this isn't templated to take any argument type, or to take a vector of any type: it only matches a const reference to a vector of exactly the same type. Even though const char * is implicitly convertible to std::string , the type vector<string> is still not the same as vector<const char *> . So, no constructor matches the argument type given.

---

Then, consider

forward_list<string> words(articles.begin(), articles.end());

The std::forward_list constructors are listed here . Note number 4:

template< class InputIt >
forward_list(InputIt first, InputIt last, 
             const Allocator& alloc = Allocator() );

Firstly, this is templated on the iterator type, so passing vector<string>::iterator or vector<const char *>::iterator or whatever is no problem. Secondly, the conversion to std::string from const char * is sufficient for this overload to actually compile once it is selected.

---

Now, a couple of notes:

1. You mentioned the explicit keyword: this just prevents a single-argument constructor being used as an implicit conversion. It doesn't affect higher types though: even if string::string(const char *) is allowed as an implicit conversion, that doesn't make vector<const char *> convertible to vector<string> . That still has to go through one of vector 's constructors.

2. We're mostly talking here about how an overload (in this case an overloaded constructor) is selected. It's entirely possible the compiler can select an overload, and then still fail to compile. For example, using that second iterator range constructor, where the iterators point to some incompatible (not even explicitly convertible) type.