Re: Missed optimization with const member

[Geza Herman <geza dot herman at gmail dot com>]

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.