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,973 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to Balog Pal   
   Re: Sequence container capacity after ca   
   05 Apr 13 03:44:08   
   
   From: daniel.kruegler@googlemail.com   
      
   On 2013-04-05 07:46, Balog Pal wrote:   
   > To me that case is the same as copy-elision. For that the standard   
   > grants a license to remove a cctor/dtor pair despite it can be   
   > user-defined and can have observable behavior.  The supposed   
   > semantics suggest the actions shall cancel out properly.   
   >   
   > Is there a reason the same license to eliminate could not be   
   > provided for op new/delete pair?   
      
   How do you define such a new/delete pair? new/delete calls are   
   completely independent and there exists no control by the core   
   language for them. You can write code of the form   
      
   T* p = nullptr;   
   if (condition1)   
       p = new T;   
   ...   
   T* q = p;   
   ...   
   if (condition2)   
       delete q;   
      
   Furthermore, we can call new in one function and delete on another.   
      
   This is different for implicitly called destructors, since we can   
   always refer them to a corresponding construction in a local context   
   and the compiler always knows about the relation of the "argument" of   
   the destructor relative to the constructor.   
      
   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