hashtable local iterator

[Jonathan Wakely]

On 19/12/2011, Jonathan Wakely:
> On 19/12/2011, François Dumont wrote:
>>
>>      I have however a remark regarding this patch. For the moment, on my
>> 64bits platform, sizeof(local_iterator) is 32 while it should normally
>> be 24 for the 2 size_t and the node pointer. I thought about using
>> inheritance in _Hash_code_base type in replacement of _M_extract, _M_h1,
>> _M_h2, _M_hash fields to benefit from EBO, would it be ok ? This way I
>> could replace the static assertion:
>>
>>        static_assert(__or_<integral_constant<bool, __cache_hash_code>,
>>                            __and_<is_empty<_H1>, is_empty<_H2>,
>>                          is_empty<_Hash>, is_empty<_ExtractKey>>>::value,
>>              "Cache the hash code or make _ExtractKey, _H1 and _Hash
>> functors"
>>              " empty");
>>
>> with the more accurate:
>>
>>        static_assert(__or_<integral_constant<bool, __cache_hash_code>,
>>                                        is_empty<_HCBase>>::value,
>>              "Cache the hash code or make _ExtractKey, _H1 and _Hash
>> functors"
>>              " empty");
>>
>> because H1, H2 and Hash are never used all together.
>>
>> I already noticed that I couldn't inherit from both _Hash and _Equal
>> because those 2 types might be identical resulting in an ambiguity. But
>> between _ExtractKey, _H1, _H2 and _Hash there is no chance of ambiguity.
>
> If you use std::tuple to store the members it will automatically use
> EBO if possible.
>
> If two types might be the same use std::tuple<X,Y,X> where X might be
> empty and Y is not empty, that ensures the two X objects will not have
> the same address so can have zero size.


that also avoids any ambiguity because you use get<N> to access the
subobjects, instead of casting to a base type.