Question

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.

Answer 1

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.