[cfe-dev] [libcxx] Small semantic error in __split_buffer::__construct_at_end(size_type) ?

[Howard Hinnant]

On Aug 28, 2011, at 6:36 AM, Jared Hoberock wrote:

> I think I may have come across a small bug in the implementation of
> __split_buffer within libcxx.
> 
> __split_buffer::__construct_at_end passes a default-constructed
> value_type to __alloc_traits::construct:
> 
> template <class _Tp, class _Allocator>
> void
> __split_buffer<_Tp, _Allocator>::__construct_at_end(size_type __n)
> {
>    __alloc_rr& __a = this->__alloc();
>    do
>    {
>        __alloc_traits::construct(__a,
> _VSTD::__to_raw_pointer(this->__end_), value_type());
>        ++this->__end_;
>        --__n;
>    } while (__n > 0);
> }
> 
> This should eventually cause the invocation of value_type's copy
> constructor somewhere in the allocator.
> 
> Compare this to vector::__construct_at_end, which simply calls
> __alloc_traits::construct with no additional argument:
> 
> template <class _Tp, class _Allocator>
> void
> vector<_Tp, _Allocator>::__construct_at_end(size_type __n)
> {
>    allocator_type& __a = this->__alloc();
>    do
>    {
>        __alloc_traits::construct(__a, _VSTD::__to_raw_pointer(this->__end_));
>        ++this->__end_;
>        --__n;
>    } while (__n > 0);
> }
> 
> This should eventually cause the invocation of value_type's default
> constructor somewhere in the allocator.
> 
> I'd argue that it's important to preserve the original semantic (i.e.,
> the allocator should invoke the no-argument constructor).  It seems
> like __split_buffer::__construct_at_end should be implemented
> identically to vector's function (i.e., no need to pass along
> value_type()).
> 
> For context, this issue arose when investigating a solution to
> avoiding default initialization of elements in standard containers
> [1].
> 
> [1] http://stackoverflow.com/questions/7218574/avoiding-default-construction-of-elements-in-standard-containers

Everything you've said is spot-on!  Thanks much!

Fix committed revision 138726.

Howard