From: use_my_alias_here_at_hotmail_com@tellus.orb.dotsrc.org   
      
   >>> Again, there is no reason for any code bloat. There are no explicit   
   >>> guarantees by the language, though.   
   >>   
   >> Excuse my lack of understanding but why can't the standard guarantee   
   >> that?   
   >   
   > The standard could guarantee that, but it chooses not to.  Things like   
   > efficiency and code size are usually left as "quality of   
   > implementation" issues.  The standard is written so that compilers   
   > *can* be efficient, but they are not required to be so.   
   >   
   > In this particular example, you care very much about memory   
   > consumption, but somebody doing massively parallel processing in the   
   > cloud may care very much less.  As things stand at the moment, your   
   > compiler vendor can optimize for memory efficiency, but the compiler   
   > for the cloud-computing system can optimize for speed.   
   >   
      
   Ok, I follow the "quality of implementation" argument. So if I as a   
   programmer want to be completely in charge of the type of optimization,   
   I then use the following?   
      
   * Use 'constexpr' when to focus on speed.   
   * Use 'extern const' when to be completely sure that nobody could bloat   
   the code by taking the address to the constant.   
      
      
   In order to safely utilize constexpr fully for both speed and memory it   
   would be nice if the compilers implemented a selectable warning flag   
   that warns if a constexpr is accessed in a way that forces the compiler   
   to allocate memory for it. Does that sound like a reasonable idea?   
      
      
   Thanks,   
   Daniel   
      
      
   --   
         [ 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)