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,251 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All   
   Re: Internal move vs. copy in std::vecto   
   06 May 12 13:06:59   
   
   469b37c3   
   From: daniel.kruegler@googlemail.com   
      
   Am 06.05.2012 10:20, schrieb Nikolay Ivchenkov:   
   > On 6 May, 08:10, Nikolay Ivchenkov  wrote:   
   >> 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.   
   >   
   > Here should be "call to the copy ctor" instead of "call as specified   
   > in the definition of the CopyInsertable requirement".   
      
   Could you explain why?   
      
   > BTW, I don't understand the purpose of presense of member functions   
   > "construct" and "destroy" in allocators. When may non-default   
   > behavior (as specified in Table 28) be really useful?   
      
   There exist several reasons for that:   
      
   a) You can ensure that construction/destruction is only possible via   
   an allocator that you might want to declare as a friend (or these   
   member functions solely).   
      
   b) You would like to add pre-/post- operation calls as part of the   
   construct/destroy functions for logging or statistic purposes.   
      
   c) It has been mentioned to me that it could be preferable to support   
   allocators that might do something differently than a pure copy or   
   move operation on the corresponding object T.   
      
   But I understand the reason for your critical position to that: Unless   
   we require that std::allocator's (a) construct and (b) destroy members   
   provide an (a) conditional and (b) unconditional   
   exception-specification, respectively, the current specification   
   essentially has the effect of a required code-pessimization. IMO this   
   problem is a good reason to submit another new library issue. I will   
   submit one that takes care of this part.   
      
   HTH & 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)   

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


(c) 1994,  bbs@darkrealms.ca