On Wed, Jun 20, 2012 at 10:54 AM, Tr3wory <tr3w@freemail.hu> wrote:
Hi,
Yesterday I started using Boost.Move in my project. On gcc I had the same problem like the guys here: http://lists.boost.org/Archives/boost/2011/07/184263.php
Namely, I can't define the move constructor nor the assignment operators outside my class... After some time I managed to create a minimal example (19 lines) and sent a bug report to the gcc guys: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725
So far, so good.
In the minimizing process I found something interesting: the problem vanishes if I remove the __may_alias__ attribute from the rv<> class. This got me thinking. Do we need this attribute at all?
The problematic expression is this: (It's in macros normally placed inside a class, TYPE is the name of this class.) operator ::boost::rv<TYPE>&() { return *static_cast< ::boost::rv<TYPE>*> (this); }
But rv<TYPE> is derived from TYPE so to me it looks like the two type is compatible, therefore the code didn't violate the strict aliasing rules, so the attribute is not necessary. (BTW can we violate the strict aliasing rules trough static_cast if we don't do any chained conversion trough void*?)
On the other hand, if it's really breaks the rules then we solved the problem for gcc, but we still have undefined behavior on every other compiler.
Can we fix this somehow?
I don't know, but +1 for bringing up this issue; there was another GCC bug I filed not long ago involving the __may_alias__ attribute: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53421 I'm leaning toward agreeing with you on the strict aliasing question but I'm no expert :( - Jeff