home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,092 of 33,346   
   Kaba to Dave Abrahams   
   Re: Implicit move of an lvalue   
   04 Apr 12 12:04:14   
   
   From: kaba@nowhere.com   
      
   This same post also addresses the replies of Daniel Krügler, SG, and   
   Martin B., to avoid repeating things.   
      
   Dave Abrahams wrote:   
   > You're complaining that an lvalue ("that") passed through std::move   
   > will bind silently to an rvalue reference, but I don't understand why   
   > that's a problem for you.   
      
   Well, that was not the problem. The 'problem' is that Type&& binds to a   
   reference. The non-template function disallows it, while an innocent-   
   looking generalization (by a template function) to an arbitrary type   
   allows it.   
      
   > After all, std::move(x) *means*: "I grant   
   > explicit permission to move from x, even if it's an lvalue."  If you   
   > want to move only when the argument to f is an rvalue, then you write:   
   >   
   >        A b(std::forward(that));   
   >   
   > Seeing "Type&& that" in the declaration of f makes it look a bit like   
   > "that" is bound to an rvalue, but it isn't (necessarily) so you can't   
   > blithely use move() on it.   
      
   Yes, this is clear, and this should be done after you are in the   
   template function definition. My post referred to whether the template   
   function should be callable at all with an lvalue (C++11 states that it   
   is).   
      
   This reminds me a bit of the situation where the conversion operators   
   are implicit by default, while a better choice would have been to have   
   them explicit by default. Here the reference collapse rule   
   A& && --> A& works by default, and can be disabled explicitly as Daniel   
   Krügler shows. But perhaps a better choice would have been to have that   
   rule disabled by default, and enabled explicitly by some notation (as   
   Daniel Krügler and SG suggest).   
      
   Watching the Going Native 2012 videos, I was positively impressed by the   
   quality of the Clang error messages. Perhaps such heuristics will save   
   us from making the mistake of moving instead of forwarding in this case.   
      
   --   
   http://kaba.hilvi.org   
      
      
         [ 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca