From: daniel.kruegler@googlemail.com   
      
   Am 27.09.2011 19:29, schrieb Dave Abrahams:   
   > on Mon Sep 26 2011, Daniel Krügler    
   wrote:   
   >> 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.   
      
   Thanks Dave, I certainly feel honored (Just to be be clear: I'm not   
   kidding!).   
      
   > Your moved-from objects have to be "valid" in some very real sense.   
      
   Let me explain that what I described is similar to the model of pointer   
   invalidation. Just ensure that these objects are in the end still   
   destructible and assignable, everything else is an invalid operation. I   
   described that as a consistent strategy still being neutral on whether   
   this is a good idea for a string or not.   
      
   > First of all, unless your code is very unusual, the object is *going* to   
   > be destroyed.   
      
   Yes, but therefore I added the remark to make it destructible.   
      
   > If you're using them with the standard library, it may   
   > (move- or copy-) assign into them.   
      
   Again, I described move- and copy-assignment as necessary (otherwise I   
   wouldn't use it).   
      
   > 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.   
      
   Certainly, therefore I described this state as a non-valid one. (Again:   
   I only tried to describe a consistent strategy, not one that I would   
   recommend for this type)   
      
   > 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.   
      
   I whole-heartedly agree. I must say that my descriptions where written   
   assuming that this string class has not been yet in "public usage"   
   (Don't ask me why I assumed it). If we have the constraints on   
   backward-compatibility, my model clearly is a no-go.   
      
   Greetings from Bremen,   
      
   Daniel   
      
      
   --   
         [ 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)