Re: hashtable local iterator

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

On 19 December 2011 21:58, Marc Glisse wrote:
> On Mon, 19 Dec 2011, Jonathan Wakely wrote:
>
>> On 19 December 2011 21:01, Marc Glisse wrote:
>>>
>>> #include <iostream>
>>> #include <tuple>
>>> struct A{};
>>> int main(){
>>> ? ? ? ?std::cout << sizeof(std::tuple<A,A,int>) << std::endl;
>>> ? ? ? ?std::cout << sizeof(std::tuple<A,int,A>) << std::endl;
>>> ? ? ? ?std::cout << sizeof(std::tuple<int,A,A>) << std::endl;
>>> }
>>>
>>> and it output 8, 8 and 4.
>>> (if I have more than 4 A at the end, the size will increase)
>>
>>
>> I suppose I should have tested it before making that claim :)
>>
>> Still, using tuple can use the EBO, even if not always optimally,
>
>
> In this case, it is a weird quirk in the itanium ABI that is causing this,
> so it looks like we are stuck with it for a while.

In Francois's unordered containers situation we can certainly live
with only one instance of the type having zero size, the other will
still use the EBO.  For std::tuple<A,B,int> where A and B are both
empty the size is always 4, for any permutation of the types.

> But generally, it is quite hard to get a good layout. I wonder if tuple
> shouldn't make a stronger effort to compact the structure, say by sorting
> the elements, empty types first, then by decreasing size. That would
> complicate the implementation quite a bit, but it might be worth it.

It might be worth doing it for an internal EBO helper type, which
doesn't need to provide the full tuple interface, but I'm not
convinced it's worth it for std::tuple as I think it would be quite
complicated.

It might be better to add a front-end attribute telling the compiler
it's allowed to re-order base classes for optimal layout, because
users can't rely on tuple having any particular layout anyway.