From: dave@boostpro.com   
      
   on Sat Apr 28 2012, Dave Abrahams  wrote:   
      
   >> 23.3.6.3/2 and 23.3.6.3/12 pertain to vector::reserve and   
   >> vector::resize, respectively, and both say the same thing:   
   >>   
   >>>   If an exception is thrown other than by the move constructor of   
   >>>   a non-CopyInsertable type, there are no effects.   
   >>   
   >> In other words, these operations offer the strong guarantee for   
   >> copyable types.   
   >   
   > Umm.  Given that I can't find a definition of CopyInsertable   
   > anywhere I am reluctant to draw any conclusions about the   
   > meaning of that language.   
      
   Okay, here's where I "blame the tools": Apple's Preview application   
   found the definition but made it really easy to overlook.  Switching   
   to Skim.app for all further PDF searches.  Howard H. helpfully handed   
   me the reference: [container.requirements.general] paragraph 13 bullet   
   1.   
      
   I agree with your interpretation of that language.   
      
   >> An implication is that move operations may replace copy operations   
   >> only if the move operations are known not to throw.   
   >   
   > That's true in the context of vector::push_back   
      
   And in the case of reserve and resize.   
      
   >> This is consistent with 23.2.1/10 above.   
   >>   
   >> 23.3.6.5/1 specifies the details for std::vector's insert,   
   >> emplace_back, emplace, and push_back operations. It says:   
   >>   
   >>>   If an exception is thrown other than by the copy constructor,   
   >>>   move constructor, assignment operator, or move assignment   
   >>>   operator of T or by any InputIterator operation there are no   
   >>>   effects. If an exception is thrown by the move constructor of a   
   >>>   non-CopyInsertable T, the effects are unspecified.   
   >>   
   >> This provision overrules the specification in 23.2.1/10 (as   
   >> 23.2.1/10 expressly notes). My reading of it is that if the copy   
   >> constructor, the move constructor, the (copy) assignment operator,   
   >> or the move assignment operator of the contained type (T) throw,   
   >> all bets are off: there is no exception-safety guarantee offered by   
   >> the standard.   
   >   
   > Not quite; there's no strong guarantee, but the standard still gives   
   > the basic guarantee—as it does everywhere and all the time—if the   
   > copy constructor of T throws.  And I think saying "all bets are off"   
   > in this context is a bad idea; people usually associate that with   
   > undefined behavior.   
   >   
   >> What the purpose of the final sentence is, I don't know, because it   
   >> simply states that if there is a noncopyable type (implying that   
   >> shifting element values must be accomplished via move operations),   
   >> there is no exception-safety guarantee.   
      
   Actually, it says that if T is noncopyable *and its move constructor   
   throws*, you get only the basic guarantee rather than the strong   
   guarantee.   
      
   >> But I believe that the first sentence already says that.   
   >   
   > Again, I don't know what it says, because I can't find a definition   
   > of CopyInsertable.  But I can report confidently on the intention of   
   > the committee.   
      
   Actually I agree with you again: that sentence seems entirely   
   redundant to me.   
      
   --   
   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)