On 8/22/2011 1:36 AM, Nevin Liber wrote:
On 21 August 2011 21:15, Eric Niebler <eric@boostpro.com> wrote:
This is the accepted dogma,
For good reason. These are places that end up getting aggressively optimized, so code that appears to work today suddenly is broken tomorrow when the compiler is revved.
Stepanov argues that things like UNDERLYING_TYPE and move_raw should be part of the Standard Library and guaranteed to work. It could have a home in Boost, too. There is precedent for having code in Boost that is non-compliant -- just under compiler switches. Boost.Typeof is non-compliant. So are parts of Boost.Foreach. And sometimes new compilers come out that break Boost.Foreach and I have to fix the compiler work-arounds. So what? Besides, I think you're getting hung up on the bitwise copy thing. Stepanov is merely making the point that some things can be implemented more efficiently with a move-like operation that makes weaker guarantees than move.
However, I might prefer a more
conservative approach whereby users must opt-in to the memcpy implementation instead of making it the default.
How often is this thing needed? The only times you need this is when the compiler generated move constructor/assignment operators either are deleted or are doing the wrong thing.
No. Nevin, at this point its obvious to me you haven't read the paper. Please go read it and then we can talk about the pros and cons. It is needed when implementing an algorithm for which move is *inherently* an inadequate tool for the job because it makes guarantees that are not needed: namely the destructability of the moved-from object. Preserving that invariant is not needed if you will be moving a valid value back into the moved-from object before its lifetime ends. Again, Stepanov does a good job describing all this. Read the paper.
Is that really the time you don't want people thinking about how to correctly write swap (or better, just write the correct move constructor and assignment operator).
Missing the point.
Even examining the implementation for all your member variables isn't enough. The boost::function which holds a boost::bind(..., this, ...) where the function object is stored inside the boost::function object itself may now exhibit different semantics than when the function object it is holding is in the heap. Ugh.
And care would be needed to write the move_raw for such an object. Just as care would be needed to write move contruct/assign and copy construct/assign for that thing.
Way back when, C++ did bitwise copying for the compiler generated copy operations, and was changed to member wise copying for good reason. I really don't want to go back to that world.
Nobody is arguing for that. -- Eric Niebler BoostPro Computing http://www.boostpro.com