From: dave@boostpro.com   
      
   on Mon Sep 26 2011, Daniel Krügler  wrote:   
      
   > Am 26.09.2011 20:27, schrieb Thiago Adams:   
   >> 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) ?   
      
   I suggest, as John W did, the use of mutable.   
      
   > 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.   
      
   No, I'm sorry.  Daniel is almost always right, but in this case I have   
   to disagree.   
      
   Your moved-from objects have to be "valid" in some very real sense.   
   First of all, unless your code is very unusual, the object is *going* to   
   be destroyed.  If you're using them with the standard library, it may   
   (move- or copy-) assign into them.  But more than that, to maintain your   
   own sanity and communicate with users of your class, you should be   
   rigorous about your notion of what a "valid" object is:   
      
     A valid object is one that meets its class invariants   
      
   All states that instances of a class can reach (intentionally, in the   
   absence of bugs) must be considered to be within its class invariant.   
      
   In general, for move, this ends up meaning the class has to have an   
   "empty" state.  Now, it's perfectly legitimate to put preconditions on   
   some of the class' operations that say, "the object must not be empty if   
   you want to use this."  For example, a std::vector must not be empty if   
   you want to use pop_back(), back(), or front().   
      
   If your class doesn't have an empty state today, and you want to add   
   move semantics, this means weakening the class invariant to include the   
   empty state.  C'est la vie.  Either bite the bullet, or don't add a move   
   operation.   
      
   --   
   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)