On 07/05/2017 01:14 PM, Jonathan Wakely wrote:
I think the reason it's not optimized away is for this case:
void somefunction(const Object& object);
{
void* p = &object;
object.~Object();
new(p) Object();
}
This means that after calling someFunction there could be a different
object at the same location (with a possibly different value for that
member).
https://stackoverflow.com/questions/39382501/what-is-the-purpose-of-stdlaunder
I don't know whether the anwser at stackoverflow is right, but: the
compiler can assume that m_initType doesn't change, if I don't launder
it. (in this case, though, I don't know how would I tell the compiler
that it must call the destructor "laundered".)
However, for this specific case that's also not possible, because
there are no constructors that could initialize the member to anything
except zero. But that requires more than just control-flow analysis,
it also requires analysing all the available constructors to check
there isn't one that does:
Object::Object(int) : m_initType(1) { }
My real code has a constructor like that. But in this case, the compiler
knows the value Object was initialized with, and could optimize access
m_initType in ~Object() too.