From: dave@boostpro.com   
      
   on Wed Mar 28 2012, Marc  wrote:   
      
   > Dave Abrahams  wrote:   
   >   
   >> on Mon Mar 26 2012, Marc  wrote:   
   >>   
   >>> For some context, yes it can make sense to have an operator< that eats   
   >>> its rvalue arguments,   
   >>   
   >> I guess I'll have to take your word for it.   
   >   
   > I can't describe the example that prompted the post, but think instead   
   > of an operator< implemented by forwarding its arguments to operator-   
   > and looking at the sign of the result. I think you'll agree that it   
   > makes sense for operator- to eat its arguments? Or if you compare two   
   > fractions, you could try doing the multiplications in-place in the   
   > numerators.   
      
   right... what doesn't make sense is using rvalue-returning iterators   
   with such a predicate in almost any algorithm at all.  For example,   
   merge or sort would produce nonsense results, because the comparison   
   would mutate the data.   
      
   >> I view move_iterator (and anything else that returns an rvalue reference   
   >> when dereferenced) as sort of a clever hack for getting more re-use out   
   >> of certain existing algorithms.  They probably shouldn't be thought of   
   >> as a general tool or used liberally, but if you know enough about the   
   >> implementation of a given algorithm, you can use move_iterator to avoid   
   >> writing a very similar implementation for an algorithm that does   
   >> something different.  For example, you can use std::copy with   
   >> move_iterator to produce an algorithm that moves elements from one range   
   >> into another.   
   >   
   > Well, std::copy is the one algorithm that you'll never use directly   
   > with move_iterator, since there is std::move for that   
      
   One of two (see std::copy_backward/move_backward) But I hope you'll   
   agree my point stands.  s/copy/transform/, OK?  Note: it can only work   
   if the predicate takes its arguments by value since the predicate itself   
   is not allowed to modify the range.   
      
   > (although you could use std::copy with a template iterator that will   
   > sometimes be normal and sometimes a move_iterator).   
      
   Yeah, that's exactly what I'm saying you typically *won't* do.  You   
   should almost never find yourself in a generic context where you don't   
   know whether the source sequence is going to be mutated (moved) or not.   
      
   > This "if you know enough about the implementation" doesn't really feel   
   > right.   
      
   I mean, essentially, "if you're the implementor of the algorithm."   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)