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.
