http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653
Bug #: 51653
Summary: More compact std::tuple
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Created attachment 26166
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26166
proof of concept
Hello,
as a low priority enhancement possibility, I think it would be nice if
std::tuple was more compact. This would allow people to just use tuple<field1,
field2,field3> instead of having to think about the likelihood of the size of
each field to get a good layout. For instance, sizeof(tuple<char,int,char>)
could be 2*sizeof(int) (on platforms where sizeof(int)>1) instead of the
current 3*sizeof(int) by reordering internally as int,char,char. Empty fields
could all be moved to the beginning to avoid problems with
tuple<Empty,Empty,int> having size 2*sizeof(int) (an ABI weirdness).
Independently, derivation could be used more often for _Head_base (not final
and not virtual? more restrictions?) so that tuple<char,tuple<char,int>> has
only size 2*sizeof(int) (note that this kind of compression won't happen for
POD).
The main drawback is that it will complicate code. In many cases, tuple is just
used as an intermediate (forward_as_tuple followed by get) and we don't care
about the tuple layout, so it would needlessly slow down compilation and, as
any complication, it might hinder some flaky optimizations.
There are 2 main ways to implement this.
- a compiler intrinsic could be created that asks the compiler to reorder bases
for a dense layout (suggested by Jonathan Wakely). Note that this is not pragma
pack, as things should remain properly aligned.
- a pure library solution is possible too. I am attaching a proof of concept. I
know my code tends to be unreadable, but it shows that, taking out the ordering
function, the remaining tuple code can be fairly simple (mytuple__ is 6 lines,
the body of myget is 1 line, and the rest is implemented on top without needing
to know how the basis is implemented). Obviously I didn't implement the whole
interface.
