variant vs strict aliasing rules

[a***@googlemail.com]

Hello,

the implementation of something like boost variant, to switch types, will
call the destructor of one type, and then call in-place new of the other
type with the same memory. What is in the standard or how does variant have
to be implemented to avoid violation of the strict aliasing rule? Or in
other words, how does the compiler know not to reorder the in-place new
before the destructor call because the two cannot possibly alias?

Thanks for enlightenment!

Arno

[Öö Tiib]

Post by a***@googlemail.com
the implementation of something like boost variant, to switch types, will
call the destructor of one type, and then call in-place new of the other
type with the same memory. What is in the standard or how does variant have
to be implemented to avoid violation of the strict aliasing rule? Or in
other words, how does the compiler know not to reorder the in-place new
before the destructor call because the two cannot possibly alias?

Standard rather explicitly describes how the lifetimes of objects (and
placement news and implicit calls to destructor) work in [basic.life].

Copy-paste of 3.8/4 ... :
A program may end the lifetime of any object by reusing the storage which
the object occupies or by explicitly calling the destructor for an object
of a class type with a non-trivial destructor. For an object of a class
type with a non-trivial destructor, the program is not required to call
the destructor explicitly before the storage which the object occupies
is reused or released; however, if there is no explicit call to the
destructor or if a delete-expression (5.3.5) is not used to release
the storage, the destructor shall not be implicitly called and any program
that depends on the side effects produced by the destructor has
undefined behavior.

I do not see how strict aliasing rules have any power here to somehow
change the defined by standard behavior.