On 5/12/2010 3:16 AM, Ion Gaztañaga wrote:
On 11/05/2010 8:48, Jeffrey Lee Hellrung, Jr. wrote:
In my opinion, *the* primary goal of this library is to provide a standardized convention by which data structures and algorithms within and outside of boost can make use of move semantics in c++03 (there is already such a convention in c++0x).
The aim is also to provide a portable syntax between C++0x and C++03 compilers, that's why I consider the macros necessary. I would like to offer a syntax any novice could easily understand.
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.
I also understand your position when you say:
This means, for example, that, as an author of some class, I am not restricted to using the macros provided by this library to enable move emulation, or the forwarding functions this library provides, or whatever else, if they don't meet my requirements.
but I, as a writer of an algorithm, would like to know how the emulation works and what should I expect when assigning temporary copyable and movable classes. If the performance depends on the emulation used by the author, maybe I can't design the algorithm optimal for both C++0x and C++03.
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.
I believe an itemization of the nitty-gritty requirements that a class must satisfy to be move-aware will encourage alternative, more targeted methods to enable move emulation while remaining inter-compatible with each other.
As long as they are compatible, there is no problem, but I think having a C++0x-like syntax for move emulation is positive. Maybe both approaches should be available, the macro-based one for average users without forbidding the use of alternative approaches.
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. Don't get me wrong, *some* standard macro should be supplied that enables move emulation with the same syntax in both c++03 and c++0x (and, based on the arguments in my previous email, this should be, at least, the "safe"/"friendly" version, and, optionally, the "optimal" one as well). Like you said, I think, at the same time, the emulation machinery should be exposed in the interface to allow for alternative approaches.
Thanks for your comments, best,
Ion
- Jeff