Re: empty base optimization vs. final class or virtual base

[Jonathan Wakely <jwakely.gcc@xxxxxxxxx>]

On 7 June 2012 21:05, Kalle Olavi Niemitalo wrote:
> In GCC 4.7.0, std::vector<_Tp, _Alloc> internally uses
> std::_Vector_base<_Tp, _Alloc>::_Vector_impl, which derives from
> the allocator class (found via std::allocator_traits).  If the
> allocator class is final (in C++11) or has a virtual base that
> lacks a default constructor, then compilation will fail.
>
> The GCC implementation of std::tuple uses the empty base
> optimization only "for empty, non-final types", so it does not
> have this problem.
>
> * Should I file a bug for adding similar checks in std::vector?

No thanks, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365 is still
open until I fix it for final allocators in containers.

>  It seems unlikely that anyone would use such weird allocators
>  in real programs, especially as std::scoped_allocator_adaptor
>  is explicitly specified to derive from the user's allocator.

That's why it's not a high priority for me to fix it.

> * In my own templates intended to be portable, what is a good way
>  to apply the empty base optimization only if it is safe?  It
>  seems to require an awful lot of boilerplate code, and I don't
>  think __is_final is standard.

If you have at least two members, one or more of which might be empty,
then store them in a std::tuple to automatically use the EBO if
possible.

e.g. std::unique_ptr has to store a pointer and a possibly empty
deleter, so it has a member of type std::tuple<pointer, D>. If D is
empty and non-final then the tuple is the same size as the pointer.
std::tuple knows how to check for final classes and handle them
appropriately.

If it wouldn't break the ABI then I would use std::tuple in all the
containers to use the EBO for allocators.