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