home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,253 of 33,346   
   Wil Evers to Nikolay Ivchenkov   
   Re: Internal move vs. copy in std::vecto   
   06 May 12 17:03:06   
   
   2373dc89   
   From: bouncer@dev.null   
      
   Nikolay Ivchenkov wrote:   
      
   > On 29 Apr, 23:59, Dave Abrahams  wrote:   
   >> on Sat Apr 28 2012, Wil Evers  wrote:   
   >>   
   >> > Dave Abrahams wrote:   
   >>   
   >> >> vector reallocation should use move operations when T's copy   
   >> >> constructor is noexcept and copy operations otherwise.   
   >>   
   >> > You probably meant   
   >>   
   >> >   vector reallocation should use move operations when T's _move_   
   >> >   constructor is noexcept and copy operations otherwise.   
   >>   
   >> > Right?   
   >>   
   >> Exactly right.  Thanks for catching the mistake.   
   >   
   > That still seems to be wrong. 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.   
   >   
   >      struct X   
   >      {   
   >          X(X &&) {}   
   >          X(X const &); // has no definition in the program   
   >      };   
      
   I experimented a little bit with gcc-4.7.0, and FWIW, I did run into a   
   surprise when adding move semantics to a C++-98-style noncopyable   
   type.  This is what I tried:   
      
     #include    
     #include    
      
     class elem {   
     public :   
       elem() { }   
       elem(elem&&) { std::cout << "elem(elem&&)" << std::endl; }   
      
     private :   
       // Disable copying (C++98 style)   
       elem(const elem&); // not defined   
     };   
      
     int main()   
     {   
       std::vector vec;   
       vec.emplace_back();   
       vec.reserve(vec.capacity() + 1);   
      
       return 0;   
     }   
      
   This caused the compiler to complain that elem's copy constructor is   
   not accessible. (The actual instantiation traceback is quite   
   interesting, but I'll leave that out for now.)  Because elem's move   
   constructor may throw, the compiler insists on using the copy   
   constructor - even though it is inaccessible.   
      
   To get the code to compile, one has to either decorate the move   
   constructor with 'nothrow', or the copy constructor with '= delete'.   
   I wonder how many C++ users will understand which of these to pick,   
   and when.   
      
   - Wil   
      
      
   --   
         [ 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca