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