Re: hashtable local iterator

[Marc Glisse <marc dot glisse at inria dot fr>]

On Mon, 19 Dec 2011, Jonathan Wakely wrote:

> On 19 December 2011 21:58, Marc Glisse wrote:
> > 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,

I admit I didn't look at the example and just jumped on the occasion to 
post about this ;-)


> > 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.

Actually, I meant it would be useful for users, not internally to 
libstdc++. Even an experienced user may get confused by the fact that 
tuple currently stores the elements in reverse order.

The interface of tuple doesn't seem so large to me, it is basically 
initialization, std::get, and a few things that can be implemented on 
top of those 2. However, thinking a couple minutes about it, it seems much 
easier to implement compressed_tuple on top of the existing tuple :-(

> It might be better to add a front-end attribute telling the compiler
> it's allowed to re-order base classes for optimal layout,

That would certainly make the library part much easier :-)

--
Marc Glisse