From: 0xCDCDCDCD@gmx.at   
      
   On 29.09.2011 00:08, Daniel Krügler wrote:   
   > 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).   
   >   
      
   Thanks for this nice explanation!   
      
   Isn't this something that could be improved in a future version of the   
   standard? C++ already considers a local l-value as an r-value on return,   
   wouldn't it make sense to "ignore" the constness? After all, the object   
   *is* gonna be destructed right away, and for it's dtor, the constness is   
   irrelevant (or so I like to think).   
      
   cheers,   
   Martin   
      
      
   --   
   Stop Software Patents   
   http://petition.stopsoftwarepatents.eu/841006602158/   
   http://www.ffii.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)