Re: Share ebo helper throughout lib

[Jonathan Wakely <jwakely@redhat.com>]

On 25/07/18 21:53 +0200, Marc Glisse wrote:
>On Wed, 25 Jul 2018, François Dumont wrote:
>
>>    It has already been noticed that there are 2 ebo helpers in the 
>>lib. Here is a patch to use 1.
>>
>>
>>    * include/bits/ebo_helper.h: New.
>>    * include/Makefile.am: Add latter.
>>    * include/Makefile.in: Regenerate.
>>    * include/bits/hashtable_policy.h: Adapt.
>>    * include/bits/shared_ptr_base.h: Adapt.
>>
>>Tested under linux x86_64.
>>
>>Ok to commit ?
>
>I don't think we support [[no_unique_address]] yet, but assuming we 
>soon will and we enable it also for C++03 (at least with the 
>__attribute__ syntax and/or in system headers), do you know if some 

Yes, I hope we'll have that soon.

>similar helper will still be necessary, with a simpler implementation, 
>or if the attribute will magically get rid of it?

We'll be able to replace some uses of EBO with the attribute
(specifically, in std::tuple). In some places we'll want to only apply
the attribute under the same conditions as we currently use the EBO,
because otherwise we'd change the layout ("compressing" the member
using the attribute where we previously didn't compress it).

In some cases that will be OK because it's an internal implementation
detail, or because we can replace e.g. _Sp_counted_deleter with
_Sp_counted_deleter_v2. In other cases we must avoid any layout change
(e.g. std::tuple).

Concretely, we probably don't want to change the layout of the
hashtable types. We could change the layout for shared_ptr
_Sp_counted_xxx types (gaining some additional space savings for final
types that currently can't be EBO'd) as long as we rename them to
avoid the linker trying to combine incompatible definitions. So on
that basis, maybe we don't want to bother changing the _Sp_ebo_helper
for now.