implicit constructor conversion works on explicit vector::vector, only sometimes

I like to initialize 2-dimensional arrays as vector<vector<int> >(x,y). x is passed to vector<vector<int> >'s constructor and y is passed to vector<int>'s constructor, x times. Although this seems to be forbidden by C++03, because the constructor is explicit, it always works, even on Comeau. I can also call vector::assign like this. But, for some reason, not vector::push_back.

        vector< vector< int > > v( 20, 40 ); // OK: convert 40 to const T&
        v.assign( 30, 开发者_开发技巧50 ); // OK
        v.push_back( 2 ); // error: no conversion, no matching function, etc.

Are the first two examples actually compliant for some reason? Why can I convert 40 and 50 but not 2?

Epilogue: see http://gcc.gnu.org/onlinedocs/libstdc++/ext/lwg-defects.html#438 for why most compilers allow this, but the standard is shifting the other way.

Your assumption about Comeau implicitly calling an explicit constructor is most likely incorrect. The behavior is indeed broken, but the problem is different.

I suspect that this is a bug in the implementation of Standard Library that comes with Comeau, not with core Comeau compiler itself (although the line is blurry in this case).

If you build a quick dummy class that has constructor properties similar to std::vector and try the same thing, you'll discover that the compiler correctly refuses to perform construction.

The most likely reason why it accepts your code is the well-known formal ambiguity of two-parameter constructor of std::vector. It can be interpreted as (size, initial value) constructor

explicit vector(size_type n, const T& value = T(),
                const Allocator& = Allocator());

or as (begin, end) template constructor with the latter accepting two iterators

template <class InputIterator>
  vector(InputIterator first, InputIterator last,
         const Allocator& = Allocator());

The standard library specification explicitly states that when two integral values are used as arguments, the implementation must make sure somehow that the formed constructor is selected, i.e. (size, initial value). How it is done - doesn't matter. It can be done at the library level, it can be hardcoded in the core compiler. It can be done in any other way.

However, in response to ( 20, 40 ) arguments Comeau compiler appears to erroneously select and instantiate the latter constructor with InputIterator = int. I don't know how it manages to compile the specialized version of the constructor, since integral values can't and won't work as iterators.

If you try this

vector< vector< int > > v( 20U, 40 ); 

you'll discover that the compiler reports an error now (since it can no longer use the two-iterator version of the constructor) and the explicit on the first constructor prevents it from converting 40 to a std::vector.

The same thing happens with assign. This certainly a defect of Comeau implementation, but, once again, experiments show that most likely the required behavior was supposed to be enforced at the library level (the core compiler seems to work OK), and somehow it got done incorrectly.

On the second thought, I see that the main idea in my explanation is correct, but the details are wrong. Also, I can be wrong about calling it a problem in Comeau. It is possible that Comeau is right here.

The standard says in 23.1.1/9 that

the constructor

template <class InputIterator>  
X(InputIterator f, InputIterator l, const Allocator& a = Allocator())  

shall have the same effect as:

X(static_cast<typename X::size_type>(f),  
  static_cast<typename X::value_type>(l),  
  a)  

if InputIterator is an integral type

I suspect that if the above is interpreted literally, the compiler is allowed to assume that an explicit static_cast is implied there (well... so to say), and the code is legal for the same reason static_cast< std::vector<int> >(10) is legal, despite the corresponding constructor's being explicit. The presence of static_cast is what makes it possible for the compiler to use the explicit constructor.

If the behavior of Comeau compiler is correct (and I suspect that it is in fact correct, as required by the standard), I wonder whether this was the intent of the committee to leave such a loophole open, and allow implementations to work arount the explicit restriction possibly present on the constructor of vector element.

Are the first two examples actually compliant for some reason?

They are not compliant on the compiler I just tried. (gcc 4.4.1)

Why can I convert 40 and 50 but not 2?

Since the first two lines are not consistent with the standard, only Comeau may know why their inconsistency is inconsistent.

It is not an accident that the standard requires explicit conversions from int types to arbitrary vectors. It is done to prevent confusing code.

vector< vector< int > > v( 20, 40 ); use a constructor that you might not be familiar with. The constructor is called here is vector(iterator start, iterator end);

Internally, it specializes to an int iterator, so the first parameter is treated as count, and second parameter is the value to initialize the vector. Because there is a cast when assign the second parameter to a vector value, so the constructor of the inner vector<T>(int, const T&) will be called with value 40. Therefore, the inner vector is constructed with 40 0's.

Your examples aren't compliant. The constructor is explicit as you said, so you not allowed to pass an int (y) instead of a vector for the constructor (and y is not passed "x times" to vector constructor: the second paramater is only created once, to initilialize the inserted objects). Your examples don't work under gcc (4.4 & 4.5).