On 5/6/2010 8:36 PM, OvermindDL1 wrote:
Greetings Boost Developers and Users,
It's my pleasure to announce that the review of Ion Gaztañagas' Move library starts May 10th and lasts until May 24th, 2010, unless an extension occurs.
First, again, I want to thank you, Ion, for putting this library together and listening to all the comments up to this point. The documentation is very well done, as it always has been. Also, thank you OvermindDL1 for volunteering as review manager. Second, I have to admit that I do have some reservations with this incantation of the library. I will be trying to post multiple comments over the next couple days, as I think of things and get around to expressing my ideas. 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). All the macros, moving and forwarding functions, move iterators, etc., are, I believe, secondary to introducing boost::rv<T>& and what that little class is suppose to represent and how T should interoperate with it. What I would like to see are a set of requirements for a type to be MovableCopyable, or MovableNoncopyable. I'd imagine this would essentially consist of a conversion operator to boost::rv<T>&, constructor accepting a boost::rv<T>&, an assignment operator accepting a boost::rv<T>&, and the semantics associated with these member functions. 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. For example, one may want to only conditionally enable move emulation, depending on whether its member objects are movable or not. Why might one not want to enable move emulation? If you enable optimal emulation, you wind up with a class that doesn't play well with enclosing classes that don't explicitly define an assignment operator. Minimizing the proliferation of such classes could be a good idea. Also, if you're just gonna define copy assignment in terms of a copy-and-move or a copy-and-swap, there's no point in using optimal move emulation, since your copy assignment operator may as well accept by value anyway. I'm hoping these considerations might convince you that there is no "one size fits all" macro to enable move emulation. 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. Regarding the macro BOOST_MOVE_OPTIMIZED_EMULATION: I think this is a bad idea, but perhaps I'm missing something. It seems like as soon as you mix in some move-enabled class into your code that *must* use the non-optimal move emulation (either by design, or through its interaction with other enclosing classes that fail to explicitly define a copy assignment operator), *all* your move-enabled classes will have to use the "safe" (i.e., non-optimal) move emulation. The only serious use case I see is when BOOST_MOVE_OPTIMIZED_EMULATION is always left undefined. Am I missing something? If not, then I think we should either 1) offer *only* the "safe" option, for simplicity; or 2) offer both options as separate move emulation enabling macros. Hopefully this will be something to at least get discussion started. - Jeff