search for: myotherclass

...memory location. In practice, this could happen if the memory allocator becomes visible to the optimizer through inlining. For illustration, do placement new into the stack memory of another object. This is illustrated in example 2 of the proposal: struct MyClass { virtual void foo(); }; struct MyOtherClass : MyClass { virtual void foo(); }; int main() { MyClass c; c.foo(); // Reuse the storage temporarily. UB to access the object through ‘c’ c.~MyClass(); auto c2 = new (&c) MyOtherClass(); c2->foo(); //fine, we have new pointer // c.foo() // UB, the type has changed // The...

...happen if the memory allocator becomes visible to the > optimizer through inlining. For illustration, do placement new into > the stack memory of another object. This is illustrated in example 2 > of the proposal: > > struct MyClass { > virtual void foo(); > }; > struct MyOtherClass : MyClass { > virtual void foo(); > }; > int main() { > MyClass c; > c.foo(); > // Reuse the storage temporarily. UB to access the object through ‘c’ > c.~MyClass(); > auto c2 = new (&c) MyOtherClass(); > c2->foo(); //fine, we have new pointer >...

Having read through the proposal, I feel like I missing some of the background to understand the problem you're trying to solve. My mental model is that construction of an object creates a new abstract location in an infinite heap with each object infinitely far apart. Destruction of the object destroys the abstract location. As a result, destructing one object and constructing another

Hi folks, this summer I will work with Richard Smith on clang devirtualization. Check out our proposal: https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing And modified LangRef http://reviews.llvm.org/D11399 You can also check out previous disscussion that was started before our proposal was ready -