在 2018-08-10 18:53, Kim Gräsman 写道:
I'm worried that this might only serve to trick the compiler.
It shouldn't. If it was merely a trick then `std::aligned_storage` would be completely unusable.
Explicitly using `-fno-strict-aliasing` for GCC < 6 would seem more direct to me -- as Jonathan says, if the compiler classifies a strict aliasing rule violation as undefined behavior, and that is further used to optimize in an unexpected manner, it doesn't matter whether it warns or not. Then again, I guess disabling strict aliasing would also disable optimizations that are generally useful for LLVM as a whole. I'm reading up on safe aliasing techniques, but so far nothing stands out to me as applicable in this scenario.
The C++ standard requires creation of objects in such ways to use new expressions (a.k.a. placement new). Athough [intro.object]-3 only defines /provides storage/ for arrays of a character type or `std::byte`, the specification of `aligned_storage` and `aligned_union` in [meta.trans.other] doesn't require the type used as uninitialized storage to be an array of a character type or `std::byte` - in fact it cannot be, because alignment information is not part of the nominal type system of C and will be lost when obtaining the `type` member.
Focusing on the cast: As long as the compiler is unable to know whether a placement new has been made on the union (i.e. whether it is providing storage for another object), I don't think a standard-conforming compiler is ever allowed to ignore such possibility.
- Kim
-- Best regards, LH_Mouse
