On 12/05/2010 17:37, Jeffrey Lee Hellrung, Jr. wrote:
My intention is not to exclude this aim, I only consider it secondary to defining an agreed-upon protocol for data structures and algorithms to interoperate in a move-aware fashion within c++03.
Ok, perfect, so what do you think that protocol should look like? Just trying to get which requirements would be essential for different reviewers and try to merge them.
Precisely why the requirements of a movable type should be explicitly defined, independent of how the move emulation is superficially effected in the code (i.e., which macro you use). As long as T is efficiently constructable and assignable from rvalues and (emulated) rvalue references (rv<T>& or T&&), the algorithm shouldn't care how the move emulation is actually effected within T.
Yes, algorithms should just need that, and a few functions (move(), forward()) to do their work. They shouldn't care about macros or implementation details.
I would just like some confidence in knowing what it means to be "compatible". As it stands now, today we'll use rv<T>& to emulate an rvalue reference, and tomorrow you might change the code to use sw<T>& to emulate an rvalue reference, or something even more radical. Who knows? There's (currently) nothing in the interface of (proposed) Boost.Move to suggest that the emulation machinery is nothing more than an implementation detail, which is problematic if code tries to enable move emulation in some alternative way, e.g., conditionally.
Ok. I don't know if someone will find a better emulation implementation. If we believe that we know enough C++03 to say rv<T> is the beste possible approach, there is no problem in pushing this outside the implementation detail. But we are ties with this implementation forever, and we should be aware of that limitation. Best, Ion