That's not really a fair test since it's all in one compilation scope. I try to just make an obj which has function which takes the stuff as a parameters like: void foo(boost::uuids::uuid&, boost::uuids::uuid&)
Then the compiler cann't know where it aligned the thing on the stack or do any other quick optimizations (beyond the alignment of the type). It is fair as far as the data type is aligned regardless where it is placed: in the heap or on the stack. If you do really want to foil the case you need to get rid of data type information (as it was proposed with the conversion to the pointer to char) and information about the data size.
The fastest thing on x86 to do this might be an MMX instruction. I remember gcc doing MOVDQA to memset() a 16 byte structure. Though I remember it because it falsely assumed 16 byte alignment and crashed.
Is your beef with the compiler?
Looking at the code the performance would probably be better if a larger integer type were used and alignment>1.
I have no doubt that one can spoil any the most brilliant idea. And that is what I see in boost: with iterators and intermediate Feng shui call it leaves the stupid MS compiler no chances to deduce the original data type, its size and alignment. Being the person who is called when a program crashes or works very slow I am pretty happy with the current situation. But while hacking another sami-failed project I was asked to join a company and start a completely new project. So I just decide now if the boost is suitable for early prototyping only or it may be used in the production too. And I do not care much about the defects like this one -- they are trivial to find and fix. I am more interested in people attitude on the problems like this one because the modern C++ approach "a compiler will take care of it" does not work for me. And as you may see I can prove my words. -- Michael Kochetkov