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 31,499 of 33,346    |
|    =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All    |
|    Re: Will a const object be moved on retu    |
|    28 Sep 11 15:08:38    |
   
   From: daniel.kruegler@googlemail.com   
      
   Am 28.09.2011 11:28, schrieb Martin B.:   
   > On 27.09.2011 19:24, Thiago Adams wrote:   
      
   [..]   
      
   >> Yes I Agree. The move operation is a non-const operation.   
   >> But.. some "moves" happens just before the destructor and I guess   
   >> the only point will see the transformations is the destructor.   
   >>   
   >> For instance:   
   >>   
   >> string f()   
   >> {   
   >> string s("new string");   
   >> return s;   
   >> }   
   >   
   > Hmm ... in a move-enabled compiler & library, `s` will certainly be   
   > moved on return (if RVO doesn't kick in).   
      
   Yes.   
      
   > But what about:   
   >   
   > string f() {   
   > string const s("new string");   
   > return s;   
   > }   
   >   
   > will `s` be moved here?   
      
   The compiler is supposed to try out overload resolution as if s where an   
   rvalue. If that fails, overload resolution is tried again considering   
   the object as an lvalue (12.8 p32). What does that mean given this   
   example? Assume that type string has both a move constructor and a copy   
   constructor,   
      
   string::string(string&&); // #1   
   string::string(const string&); // #2   
      
   In the first step we consider s as an rvalue. We perform overload   
   resolution on that value. C'tor #1 is *no* successful match because the   
   class type of object s is const string, which cannot bind to string&&   
   (move-semantics still respects cv-correctness), therefore it is supposed   
   to select the c'tor #2. This step succeeds and s is effectively *copied*   
   into the result.   
      
   In other words: You cannot move an object of class type to const T   
   (Unless you are willing to provide a move constructor with parameter   
   type const string&& and to const-cast the parameter internally).   
      
   HTH & Greetings from Bremen,   
      
   Daniel Krügler   
      
      
   --   
    [ 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