e3299e98   
   From: daniel.kruegler@googlemail.com   
      
   Am 26.09.2011 20:27, schrieb Thiago Adams:   
   > I was playing with a string class which I want to represent   
   > an immutable string object.   
   >   
   > class string {   
   >    const char* const m_psz;   
   > public:   
   >    string(const char* psz) : m_psz(_strdup(psz)) {}   
   >    ~string() { free((void*)m_psz); }   
   >    //..only const methods...   
   > };   
   >   
   > When I wrote the move constructor the compiler complained   
   > about the const data member (m_psz).   
   >   
   > string(string&&  s) : m_psz(s.m_psz)   
   > {   
   >      s.m_psz = nullptr; //error l-value specifies const object   
   > }   
   >   
   > Then I realized that is not be possible to move from const data   
   > members.   
   >   
   > What would you do in this case?   
   >   
   > 1) Do not use move constructor?   
   > 2) Remove the const data member keeping the const member functions?   
   > 3) ?   
      
   It depends on what constraints you impose on moved-from objects. The   
   standard has defined the MoveConstructible/Assignable requirement sets   
   intentionally very loose to allow for different strategies for   
   user-defined types (Library types have generally stricter requirements,   
   they have the effect that all library types have a move semantics such   
   that the move-from object has an valid state, see 17.6.5.15   
   [lib.types.movedfrom] p1). So, you could define that move-from objects   
   of your class string are invalid objects. It would probably be a service   
   to your users to ensure that you can move-assign, copy-assign and   
   destruct such an object, but that is your own decision (Personally I   
   wouldn't like much to use you type, if I couldn't perform at least these   
   three canonical operations). With such a definition, it would make sense   
   to add a move-constructor with a "real" move semantics, basically with   
   the effect that you remove the constness of the pointer m_psz. The   
   disadvantage of such a definition would be that user code couldn't   
   perform all standard-provided algorithms out-of-the box because they   
   usually impose stricter requirements (We would need to see the complete   
   API of your type to discuss details of this).   
      
   But if you instead want to provide the same level of guarantees as the   
   library types to, adding move semantics for your type seems like a very   
   slippery territory to me: Note that when you assign a nullptr to the   
   source you are creating a string object with a null char pointer: This   
   would introduce a state, that was previously very rarely possible (at   
   least to the level what we see from your type: All strdup functions I'm   
   aware of (they are non-standard, but are still used as we see by your   
   posting) require that the source is a valid null-terminated char   
   sequence, no null pointer, so the result of strdup is a non-null pointer   
   unless there is no memory available to produce a copy). In this case   
   adding such a slippery move semantics with a new grey state would IMO   
   cause more trouble than advantages: Your users could easily misuse it.   
   In this case it would seem safer to add no move-semantics at all to your   
   string type and to ensure that your type is immutable in the pure sense.   
      
   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)