From: bouncer@dev.null   
      
   Dave Harris wrote:   
      
   > 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.   
      
   I would say an initializer list better reflects the way C++ handles   
   (sub-)object initialization.  Of course, if a, b, c and d are just   
   ints with no dependency relationships, it doesn't really matter.   
   However, for a class that uses more complex, user-defined member   
   types, proper initialization before the constructor body is entered   
   often does matter, especially when one member variable somehow depends   
   on another.   
      
   > 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.   
      
   A decent compiler will issue a warning if the order in the initializer   
   list doesn't match the order in the class definition.   
      
   > 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.   
      
   In many cases, the initializer list is enough, and there's no need for   
   any code in the constructor body at all.  Where I do need a body, I   
   often find that it is easier to understand if it can rely on   
   reasonably initialized member variables and base sub-objects.   
      
   Let's not forget that reading an uninitialized member variable   
   triggers undefined behavior; by always initializing them first, we at   
   least document what we expect to find there.   
      
   > Let's not even think that we might need different exception   
   > handlers.   
      
   Yes, that's a hard one.  To me, it usually serves as red flag telling   
   me I need to re-evaluate my design.   
      
   > Previous to C++11, there were things that couldn't be initialised by   
   > initialiser lists at all.   
      
   I suppose you're referring to built-in arrays?   
      
   > 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.   
      
   I would say initialization in the constructor body (instead of the   
   initializer list) makes more sense in languages that guarantee all   
   member variables have some pre-defined value we can count on.   
      
   - Wil   
      
      
   --   
         [ 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)