From: francis.glassborow@btinternet.com   
      
   On 22/04/2012 12:20, Dave Harris wrote:   
   > { 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.   
      
   You maybe right as to the motivation of the writers of the coding   
   policy, however I think those reasons are competely inadequate. They   
   should be asked to provide a rationale because without it a programmer   
   will not know when to vary from the policy.   
      
   I much prefer to see a policy that requires that everything be   
   initialised in the initialisation list unless it is impossible to do   
   so.   
      
      
   As to the order of initialisation problem, anyone who writes the   
   definition of a constructor without having the definition of the class   
   in front of them should be given a final warning for dangerous coding   
   habits.   
      
   Note that const and reference members have to be initialised in the   
   initialisation list.   
      
   Using assignment within the body of a constructor for a data member   
   should be a red flag that that member cannot be initialised.   
      
   One reason that some of us campaigned so hard to maximise the number   
   of things that could be initialised in initialisation lists was   
   exactly because we believed that the language should no be preventing   
   the programmer from using a good consistent style.   
      
      
   The solution to bad coding isn't rules but training. And it certainly   
   isn't rules that inhibit good programming style.   
      
   Francis   
      
      
   --   
         [ 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)