[PATCH] 77864 Fix noexcept conditions for map/set default constructors

Jonathan Wakely jwakely@redhat.com
Sun Oct 9 15:38:00 GMT 2016


On 09/10/16 16:14 +0100, Jonathan Wakely wrote:
>On 08/10/16 22:55 +0200, François Dumont wrote:
>>On 06/10/2016 23:34, Jonathan Wakely wrote:
>>>On 06/10/16 22:17 +0200, François Dumont wrote:
>>>>Another approach is to rely on existing compiler ability to 
>>>>compute conditional noexcept when defaulting implementations. 
>>>>This is what I have done in this patch.
>>>>
>>>>The new default constructor on _Rb_tree_node_base is not a 
>>>>problem as it is not used to build _Rb_tree_node.
>>>
>>>Why not?
>>
>>_Rb_tree_node_base is used in 2 context. As member of _Rb_tree_impl 
>>in which case we need the new default constructor. And also as base 
>>class of _Rb_tree_node which is never constructed. Nodes are being 
>>allocated and then associated value is being constructed through the 
>>allocator, the node default constructor itself is never invoked.
>
>In C++03 mode that is true, but it's only valid because the type is
>trivially-constructible. If the type requires "non-vacuous
>initialization" then it's not valid to allocate memory for it and
>start using it without invoking a constructor. If you add a
>non-trivial constructor then we can't do that any more.

In fact that code is highly questionable, because the element member
makes the node require non-trivial initialization. We rely on the base
being trivially-constructible, and the element being constructed by
the allocator, and assume that it's OK to then treat that memory as a
node. In fact only its base class and member have been constructed,
not the node itself. The C++11 version (using an aligned buffer) is
correct. But I'd prefer not to make the C++98 version worse.



More information about the Gcc-patches mailing list