Re: RE : Problem with _Hashtable_ebo_helper

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 28 October 2013 18:46, Jason Merrill wrote:
> On 10/28/2013 07:42 AM, Jonathan Wakely wrote:
>>
>> The comment and name of the parameter are a little misleading now, as
>> EBO won't be used for non-empty types, the parameter really means "use
>> inheritance" after the change, not "use EBO".
>
>
> True enough.  Incidentally, why not just always use inheritance?

Looking at the code I don't think we actually use
_Hashtable_ebo_helper with _Hash_code_base except for the
static_assert, we do just use inheritance for _Hash_code_base.

The EBO helper is meant to be used for user-provided types such as the
allocator, hash functor and equality functor, because they could have
virtual functions that would match functions in the derived type and
so interact in ways we don't want.  By only inheriting when the class
is empty we know it has no virtual functions. Which, it now occurs to
me, would not be true of a non-empty, polymorphic type with a
protected destructor.  So maybe your change isn't a good idea, and we
should just fix the static_assert that misuses _Hashtable_ebo_helper:

      static_assert(__if_hash_not_cached<
                    is_default_constructible<
                      // We use _Hashtable_ebo_helper to access the protected
                      // default constructor.
                      __detail::_Hashtable_ebo_helper<0,
__hash_code_base, true>>>::value,
                    "Cache the hash code or make functors involved in hash code"
                    " and bucket index computation default constructible");

If what we want is a type that derives from __hash_code_base in order
to check if that dervide type would be default constructible then we
should create a new type that does that, not appropriate
_Hashtable_ebo_helper for something it isn't designed for, and after
your fix doesn't even work for!