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,989 of 33,346   
   =?ISO-8859-15?Q?Daniel_Kr=FCgler?= to All   
   Re: Sequence container capacity after ca   
   21 Apr 13 15:51:14   
   
   From: daniel.kruegler@googlemail.com   
      
   Am 17.04.2013 08:33, schrieb Dave Harris:   
   [...]   
   > If the compiler can show that atype's constructor and destructor have   
   > no visible side effects, then it ought to be able to optimise away   
   > both lines. As things stand, I thought we agreed, it cannot, because   
   > the allocation and deallocation of memory count as a visible side   
   > effect (unless the compiler can prove that the user has not defined   
   > operator new and delete, which it usually can't; especially if the   
   > user has). The compiler could replace it with something like:   
   >   
   >       operator delete( operator new( sizeof atype ) );   
   >   
   > but it can't get rid of that.   
   >   
   > So the suggestion is for calls to operator new and delete to not be   
   > considered observable, even if they are defined by the user. To which   
   > the counter was made, that it would allow the compiler to replace   
   > heap-based allocation with stack-based, which the programmer may not   
   > desire. This is true: however, it would not require the compile to do   
   > so. It would become a quality of implementation issue.  Best practice   
   > might be for the compiler to only remove calls to operator new and   
   > delete if it can do so safely; for example, in cases like the above   
   > where the code would vanish entirely and no extra stack allocation   
   > would be done.   
      
   It might be worth adding that the C++ Core Language group has recently   
   accepted a proposal during the Bristol meeting that relaxes the   
   constraints upon new expressions to provide better optimizations   
   choices. In particular, an implementation is now allowed to omit calls   
   to the replaceable global allocation function, it may instead provide   
   some "own" storage or it may extend the allocation of another new   
   expression. For details please read the proposal (N3664 will be   
   available in the post-meeting mailing on   
   http://www.open-std.org/jtc1/sc22/wg21/).   
      
   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