Comment Re:Good grief... (Score 1) 681
Actually, it isn't if the compiler can prove that the layout is not visible outside of the compilation unit.
Ok, that's fair. You also need to ensure its memory image isn't visible to, say, a char*. (That pesky char* exemption in the standard that allows you to write memcpy and memmove is no friend to alias analysis.)
For example, if the address of one of these structs is never taken, then the struct never need live in memory even, so its layout is irrelevant. If addresses do get taken but you can find all the uses of those addresses, then yes, you could play games with the layout if it was impossible for the program to notice. That's perhaps a stronger criteria than compilation unit boundary, though.
What's the justification for compilation unit boundary? It seems like you could expose the layout of the struct (and therefore any compiler shenanigans) through other means within a compilation unit. offsetof comes to mind.
My initial gut reaction is that nearly any interesting data structure wouldn't qualify for this optimization.
It's much more interesting in environments with on-the-fly compilation, because then you can adapt data structures to use.
Cool. That reminds me of an experiment I heard about at HP. They implemented a PA-RISC to PA-RISC dynamic translator that used run-time information to reoptimize the code. The overall speedup (including the cost of the translator) was in the 5% - 10% range. Here's the paper.
Even then, you can do it outside of the compiler (for example, the NeXT implementations of the Objective-C collection classes would switch between a few different internal representations based on the data that you put in them).
I suppose you could do that in C++ with template specialization. In fact, doesn't that happen today in C++11 and later, with movable types vs. copyable types in certain containers? Otherwise you couldn't have vector< unique_ptr< > >. Granted, that specialization is based on a very specific trait, and without it the particular combination wouldn't even work.
In theory, you could also specialize based on, say, sizeof( item ). I suppose that then becomes an ABI issue with the C++ standard library. Bleh.
I have a love-hate relationship with C++.