On 09/22/10 15:28, Frank Mori Hess wrote:
On Wednesday 22 September 2010, Larry Evans wrote:
On 09/22/10 14:04, Frank Mori Hess wrote:
I don't see how that gets around the anti-aliasing rules. The compiler is allowed to assume incompatible pointers won't _ever_ alias. So just because your program does things in a certain order doesn't mean the compiler isn't allowed to use the anti-aliasing assumptions to reorder things in a nasty way. Couldn't it look at the destruction of the old object and the construction of the new object as two completely independent actions it is free to reorder or interleave?
I hadn't thought of the compiler reordering the calls. Just to be clear, the compiler, using the anti-aliasing rules, could reorder:
316 destroy(); 317 assign_copy(from);
to:
317 assign_copy(from); 316 destroy();
? Or maybe just do everything in destroy before the lhs->~Lhs() call, then execute assign_copy(from) and then do lhs->~Lhs(). Hmm... OK, I think I got it, but am surprised.
I think so, in principle. I only have a vague idea of what optimizing compilers actually do under the hood though, which is why I tend to be very conservative about obeying the strict aliasing rules (they've bitten me before).
A more concrete example is attached. IOW, the strict aliasing rules would allow the compiler to move: p20->~str(); after the: str<10>* p10=new(buf) str<10>; because p20 and p10 are assumed not pointing to the same location. Note: I did compile with: -O3 -Wstrict-aliasing as Mathias suggested; however, the compiler didn't issue any warnings. I'm wondering why? -Larry