Default associative containers constructors/destructor/assignment

[Jonathan Wakely]

On 20/11/16 19:14 +0100, François Dumont wrote:
>Talking about _M_color I just realize that move semantic doesn't copy 
>_M_color. Shouldn't we capture it along with all the other _M_header 
>information ?

Is it needed? I think the current code does the right thing, doesn't
it? I'd prefer not to change it without a testcase showing why we need
to.

>>Am I missing some other reason that inheritance is used here?
>
>The purpose of this patch is to rely more on compiler especially in 
>regards to the noexcept qualifications. This is why I started 
>isolating each ressource in its own class in charge of its 
>specificities. And I leave to the compiler the work of combining those 
>types. However I also wanted to limit the impact of this patch on the 
>_Rb_tree and still be able to use things like 
>this->_M_impl._M_node_count or this->_M_impl._M_header. So the usage 
>of inheritance.

OK.

I think I've convinced myself that using inheritance here can't alter
the layout in any way (I was worried about reuse of tail padding, for
example).

>Tested under x86_64 Linux, ok to commit ?

OK for trunk.

>For info, I would like to propose another bunch of simplifications of 
>_Rb_tree, see other patch attached. Do you want me to propose it in 
>another mail ?

The patch is safe enough for stage 3, so please go ahead and commit
that one too, but we need to stop refactoring these things now. Any
more changes like this need to wait for stage 1.

Thanks for this work.