23.2.1 paragraph 3 and stl_tree.h

[Jonathan Wakely]

On 15 February 2014 09:27, Jim Apple <jimapple.plusplus@gmail.com> wrote:
> In my copy of a late draft of the 2011 C++ standard, 23.2.1 (General
> container requirements) paragraph 3 reads:
>
> "For the components affected by this subclause that declare an
> allocator_type, objects stored in these
> components shall be constructed using the
> allocator_traits<allocator_type>::construct function and
> destroyed using the allocator_traits<allocator_type>::destroy function
> (20.6.8.2). These functions
> are called only for the container's element type, not for internal
> types used by the container. [ Note: This
> means, for example, that a node-based container might need to
> construct nodes containing aligned buffers
> and call construct to place the element into the buffer. -- end note ]"
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf
>
> As I read it, this applies to associative containers as well. However,
> in stl_tree.h, _Rb_tree::_Node_allocator is defined on line 349 and
> then used in _M_get_node() on line 385 using a type that is not the
> container's element type, I think.
>
> http://repo.or.cz/w/official-gcc.git/blob/7deb91c75a1c9de5bf46a5c959e5e709173ee639:/libstdc%2B%2B-v3/include/bits/stl_tree.h
>
> Have I misinterpreted the standard or the library or both?

The standard.

23.2.1 says that allocator_traits<A>::construct and
allocator_traits<A>::destroy are only used for the container's element
type. Line 385 does not call construct or destroy, it calls allocate.

Line 421 calls construct, but it does so for the element_type, because
__tmp->_M_valptr() returns a pointer to an aligned buffer in which to
construct the buffer.

There is an open issue to clarify the wording to say what was intended
by the authors of that wording, see
http://cplusplus.github.io/LWG/lwg-active.html#2218

I think with the proposed resolution there it is more obvious that the
libstdc++ implementation is correct.