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

[Jared Hoberock]

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