[tialaramex]

In the medium term I'd say it's more likely you miss out on optimizations by not clearly expressing what you actually wanted here.

The more clarity is available as to what you meant, the more aggressive the optimiser can be in delivering precisely that. If you don't express exactly what is intended, the optimisers end up getting muzzled because the effect is so confusing.

[gpderetta]

What specific optimizations would a wrapper type allow that a accessing directly a pointer to a reinterpret casted, property aligned StandardLayout type would not allow?

[tialaramex]

The concern I have isn't about optimisations that are impossible but optimisations which are judged unwise and so either disabled by default or not implemented at all.

Maybe reinterpret_cast on StandardLayout with the correct alignment really does express exactly what we want here, I'm not sure. If so you're correct there wouldn't be a difference because a valid optimisation will always be exactly what everybody wanted. But if there are any other uses of these techniques the optimiser has to be pessimistic. That's why I prefer to be as explicit as possible.

This is how so many extra types of cast came into existence in C++ in the first place right, the recognition that casting could have different intents.

[gpderetta]

> StandardLayout with the correct alignment really does express exactly what we want here, I'm not sure

Surely if you are unsure the default position should be to go to the obvious and simple solution instead of overengineering it? But I might be completely misunderstanding your point.

[If the struct is not correctly aligned, I would either memcpy or apply any required compiler pragmas, while cursing the protocol designer]