On 09/22/10 14:04, Frank Mori Hess wrote:
On Wednesday 22 September 2010, Larry Evans wrote: [snip]
Rethought that answer because I don't (yet) see where pointers to the 2 different types exist at the same time in the operator= for
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. So now, using the C++0x non-pod in union capability; however, would one generate the attribute for Spirit's alternative parser (a | b): http://www.boost.org/doc/libs/1_44_0/libs/spirit/doc/html/spirit/qi/quick_re... ? Maybe one could do what fusion does for vector, i.e. using boost/preprocessory, generates: template<T1,T2,...,Tn> struct vector_n { T1 m1; T2 m2; ... Tn mn; }; Only for the union, it would be: template<T1,T2,...,Tn> struct union_n { union { T1 m1; T2 m2; ... Tn mn; } u; }; Or something like that? Otherwise, I don't see a workaround to this strict aliasing problem :( -Larry