Patch: stl_vector.h

[Paolo Carlini]

Matt Austern wrote:

> This is slightly ambiguous, but my interpretation of the standard   
> (23.1.1/9) is
> that this is required to work.  We're selecting the constructor
> template <class InputIterator> X(InputIterator f, InputIterator l,  
> const Allocator& a = Allocator())
> and the standard says it has the same effect as
> X(static_cast<typename X::size_type>(f), static_cast<typename  
> X::value_type>(l), a)
>
> The latter constructor is well-formed.  Static cast of 1 to dvector_t  
> is well formed:
> it's the same as dvector_t(1), which invokes the single-element  
> constructor that
> creates a length-1 vector of default-constructed elements.

I think Gaby agrees with that and in principle it's fine with me too, of 
course.

> The reason there's any ambiguity at all is that the standard has a  
> non-normative
> note describing possible implementation techniques, and, using one of  
> those
> techniques, this example would fail to compile.  I think the standard  
> is clear and
> that just means this note is wrong, but some people disagree.  
> Finally:  some
> people think that, irrespective of what the standard currently says,  
> this example
> shouldn't compile.  I think that in a future version of the standard 
> it  will be
> explicitly illegal.  Pointer to the committee discussion:
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#438

Thanks for the pointer, that I didn't know. I'm really worried by the 
fact that this
will be explicitly illegal, however: in a sense we are wasting some of 
our time, taking
care of this in the light of that... Anyway, if it's just a little 
amount of time... ;)

> Obviously I missed something with the allocator work.  Sounds like 
> I'm  still
> missing it, though; I don't see an obvious reason why this dispatching
> should have anything to do with allocators.

All the ""trouble"" comes from the pair of __uninitialized_fill_n_a 
overloads that
you  added recently: the first one is for std::allocator and equivalent 
to the old
behavior, the second one is for an user provided allocator != 
std::allocator, and ends
up calling __alloc::construct with a mismatched pair of arguments...

Thanks for your feedback,
Paolo.