On Tue, May 11, 2010 at 12:48 AM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
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.
I had similar thoughts pass through my mind, I look forward to if you have a design style in your mind for later. On Tue, May 11, 2010 at 12:48 AM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
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.
Very good point, perhaps having both macros would provide the best power, any thoughts anyone else? On Tue, May 11, 2010 at 12:48 AM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
Hopefully this will be something to at least get discussion started.
A little slow due to BoostCon no doubt, but there are plenty of us that are still stuck away, so please, anyone around, do test and give input about the interface, use, efficiency, etc...