[Development] xcode emplace_back (was: QVector now has rvalue push_back)

[Matthew Woehlke]

Since this touches on a possible standards issue, CC'ing the standards list.

On 2015-07-21 13:00, Gunnar Roth wrote:
> Hello,
> Out of curiosity i just looked at the Xcode 6.4 headers for the implementation of std::vector::emplace_back,
> and i don’t think there is any difference between push_back(QPen(Qt::red,1.5f)) and emplace_back(Qt::red,1,5f))
> 
> The implementation is like this:
>     template <class... _Args>
>     _LIBCPP_INLINE_VISIBILITY void emplace_back(_Args&&... __args)
>         { push_back ( value_type ( _VSTD::forward<_Args>(__args)... )); }

>From http://www.cplusplus.com/reference/vector/vector/emplace_back/:

  "Inserts a new element at the end of the vector, right after its
current last element. This new element *is constructed in place* using
args as the arguments for its constructor." (emphasis added)

>From http://en.cppreference.com/w/cpp/container/vector/emplace_back:

  "Appends a new element to the end of the container. The element is
constructed through std::allocator_traits::construct, which typically
*uses placement-new to construct the element in-place* at the location
provided by the container." (emphasis added)

Ergo, that implementation looks... suspicious, and *may* even be
non-conforming. (Unless push_back is doing something really funky, which
I somewhat doubt.) You may want to file a bug against that implementation.

@std-discussion, since I don't have a copy of the standardese handy, is
in-place behavior (or possibly rather use of 'std::a_t::construct')
*required* for standards conformance, or is it just QoI? (Is there any
way that the above implementation can be doing in-place construction?)

-- 
Matthew