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,173 of 33,346    |
|    Dave Harris to nroberts    |
|    Re: Initialization and trivial construct    |
|    22 Apr 12 04:20:13    |
   
   5bcab1d2   
   From: brangdon@cix.compulink.co.uk   
      
   { Article reformatted; please limit your lines to 70 charaters -mod }   
      
   roberts.noah@gmail.com (nroberts) wrote (abridged):   
   > Say you were given a coding policy that stated, "Only initialize   
   > members with non-trivial constructors and destructors in your   
   > constructor's initialization list." Assuming they mean what they   
   > are saying, and understand the difference between trivial and   
   > non-trivial constructors, could there be a reasonable explanation   
   > for this policy?   
      
   They may be trying to say that:   
      
    Class::Class() : a(0), b(0), c(0), d(0) {   
    }   
      
   would be better written as:   
      
    Class::Class() {   
    a = 0;   
    b = 0;   
    c = 0;   
    d = 0;   
    }   
      
   The former may be more efficient if the members have code in their   
   constructors, but if they are just ints, then the efficiency will be   
   about the same. The latter version is arguably easier to read, write   
   and edit.   
      
   It matters more when the initialisation is more complex. For example,   
   the latter version makes the order of evaluation apparent in the code;   
   in the former version the order is determined by the class definition,   
   which may be in a different source file. If you need some code to   
   calculate the initial values, in the latter version you can just put   
   it on the previous line, and add whatever intermediate variables or   
   function calls you need. In the former version you have to write a   
   separate function to return the initial value you want, and either   
   pass lots of arguments to it, or else rely on the order of   
   initialisation which as I've already noted is fraught. Let's not even   
   think that we might need different exception handlers. Previous to   
   C++11, there were things that couldn't be initialised by initialiser   
   lists at all.   
      
   Basically, assignment statements are simple. Everyone understands   
   them. Initialisation lists are weird and full of restrictions and   
   special cases; they are part of what makes C++ hard. Sometimes you   
   need them for performance, though.   
      
   -- Dave Harris, Nottingham, UK.   
      
      
   --   
    [ 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