2373dc89   
   From: daniel.kruegler@googlemail.com   
      
   Am 06.05.2012 06:10, schrieb Nikolay Ivchenkov:   
      
   > [..] Vector reallocation should use move   
   > operations when T's move constructor has a non-throwing exception   
   > specification or the call to T's copy constructor would not be well-   
   > formed when considering immediate context; otherwise it should use T's   
   > copy constructor.   
      
   I have no strong opinion on this one. The advantage is that it would   
   support move-operations where-ever possible, but it would do that with   
   the risk of providing less exception guarantees. I'm not sure that   
   everyone would be happy with that. One further thing to notice is that   
   it would not only affect the concrete user-provided type X, but also   
   derived types, like std::pair or std::tuple, so this can lead   
   to unexpected behaviour, because the root of the problem is very deep   
   within type-"structures".   
      
   > As far as I can see now, the resolution of LWG DR 2033 bullet 5 is   
   > unsatisfactory: neither CopyInsertable nor MoveInsertable requirement   
   > is appropriate for vector's resize with single parameter, because   
   > CopyInsertable is too strict and MoveInsertable is too weak here. I'll   
   > try to explain why MoveInsertable is not sufficient. Let's consider   
   > the following type:   
   >   
   >       struct X   
   >       {   
   >           X(X&&) {}   
   >           X(X const&); // has no definition in the program   
   >       };   
   >   
   > X is not CopyInsertable, however an implementation probably would   
   > treat such a type as CopyInsertable and would call copy ctor (even   
   > though it is undefined), because is_copy_constructible::value would   
   > be equal to true. Thus, if our move ctor does not have a non-throwing   
   > exception specification and the call as specified in the definition of   
   > the CopyInsertable requirement would be well-formed in immediate   
   > context, then our type shall completely satisfy the CopyInsertable   
   > requirement. This restriction cannot be derived from the   
   > MoveInsertable requirement. I hope, Daniel Kruegler will read this, I   
   > would be glad to see his comments.   
      
   I agree with your arguments, this looks like a defect that should be   
   submitted as an LWG issue and it also does not affect vector alone. I   
   would like to encourage you to do that.   
      
   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)