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,186 of 33,346   
   Miles Bader to Dave Harris   
   Re: Initialization and trivial construct   
   23 Apr 12 21:22:27   
   
   From: miles@gnu.org   
      
   [I think a coding standard that _mandates_ avoiding initializers is   
   pretty dopey , but:]   
      
   brangdon@cix.compulink.co.uk (Dave Harris) writes:   
   >> > and full of restrictions and special cases;   
   >>   
   >> A list, please!   
   >   
   > I've already mentioned them, but if you want it in list form:   
   > o Order of evaluation may not be order written   
      
   (but this is an easy and safe [no false positives] compiler warning)   
      
   > o Unable to add more code between initialisations (so it doesn't   
   > scale).   
      
   This is absolutely my main complaint about initializer lists -- I find   
   it a very common case that I want to calculate an intermediate value   
   based on the constructor arguments, and then use that value to   
   initialize several data members.  The initializer-list form makes this   
   quite annoying.   
      
   Of course, if efficiency isn't an issue, once can just repeat the   
   calculations for each of the data members (probably calling a function   
   to avoid duplicating the actual code), but sometimes efficiency _is_   
   important... (if you're lucky, maybe the compiler can see what's going   
   on and optimize away the redundancy ... but maybe it can't....)   
      
   [Adding "intermediate code" to initialize a _single_ data-member isn't   
   that hard, because one can just use private static member functions   
   that return the initialization value.]   
      
   > o It's a different way of writing code.   
      
   I suppose, but that seems a pretty pointless argument in this context:   
   you basically _can't_ avoid initializers in any sane C++ code base, so   
   the devs are going to be using them a lot regardless -- and once   
   you're using them, you may as well use them always, because that   
   _reduces_ the variance (I'd say that initializers can be used pretty   
   painlessly like 98% of the time).   
      
   A coding standard that arbitrarily forbids using initializers for   
   cases X, Y, and Z, is just adding churn, making the code less   
   consistent and harder to understand.   
      
   -miles   
      
   --   
   Circus, n. A place where horses, ponies and elephants are permitted to   
   see men, women and children acting the fool.   
      
      
         [ 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