Patch: stl_vector.h

[Matt Austern]

On Oct 16, 2004, at 12:41 PM, Paolo Carlini wrote:

> Paolo Carlini wrote:
>
>> 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...
>
> Ok, now I see it. The problem is that _Construct (used for 
> std::allocator) has *two*
> template arguments:
>
>  template<typename _T1, typename _T2>
>    inline void
>    _Construct(_T1* __p, const _T2& __value)
>
> whereas __alloc::construct (used for __alloc != std::allocator) has 
> only one!

Aha!  Although I think the real bug was at a higher level, and was just 
masked
by _Construct.  I'm thinking of this:
       template<typename _Integer>
         void
         _M_initialize_dispatch(_Integer __n, _Integer __value, 
__true_type)
         {
	  this->_M_impl._M_start = _M_allocate(__n);
	  this->_M_impl._M_end_of_storage = this->_M_impl._M_start + __n;
	  std::__uninitialized_fill_n_a(this->_M_impl._M_start, __n, __value,
					this->get_allocator());
	  this->_M_impl._M_finish = this->_M_impl._M_end_of_storage;
	}

I don't see any static_cast<value_type>(__value) here, and the standard
says there's supposed to be one.

Putting it in shoule fix this bug.  The only annoying part is that I'm 
sure
we have exactly this same bug in a number of other places.  (Other
containers, insert, assign,...)  What with finding all those places and
putting in all the necessary test cases, this'll be a big patch.
Mechanical, but big.

			--Matt