Advantage of implicit assignment over explicit

Hi,

I recommend you read Scott Meyer's "Effective C++" and "More Effective C++". You can't call yourself a C++ programmer until you do. He explores how to write low maintenance, high quality code and definately dicusses your query above.

HTH.

For plain old data (like int) members the generated code is nearly identical.
The advantage comes when b is not plain old data.
In that situation the generated code would have a default construction followed by an assignment instead of an explicit construction. So member initialisation results in less code.
The only warning or recommendation I can give you for that case is that you should take care to ensure that the member initialisation doesn't assume a construction order for the members.

The correct term to use here is initializer list or initialization list. Since minkowski already pointed to Scott Meyer in a previous Solution, here is a thread referencing his books on this topic:
http://www.cplusplus.com/forum/articles/17820/[^]

Its more efficient to use the initializer list. Performance difference is negligible when you compare POD types and complex types but still using an initializer list is more elegant. Members get initialized even before the body of the constructor gets executed.

There are cases where an initializer list is mandatory say like when you have constants or references in your class.

Also if you have a initializer with the same name as the data member the compiler will know how to resolve these names.

class A{
int a;
public:

A(int a):a(a){}
};

implicit means that the compiler is free to automatically reinterpret an expression by converting an operand to another type through an implicit constructor. explicit means that this is forbidden.

Consider these examples:

class Complex {
private:
  double im_;
  double re_;
public:
  Complex(double re) : re_(re) {} // implicit
  Complex(double re, double im) : re_(re), im_(im) {} // not implicit
  explicit Complex(double* vec) { re_ = vec[0]; im_ = vec[1]; } // explicit
  // ...
};
void Foo() {
  Complex ca(1.0), cb(0.0, 1.0);
  double mydouble = 3.14;
  double * ar = &mydouble;
  double va[] = { -1.0, 1.0 };
  Complex cc = ca + Complex(va); // explicit constructor required!
  Complex cd = cc - 3.0; // implicit constructor called
  Complex ce = cb + ar; // error: cannot convert double* to Complex; explicit construction required
}

The last line will cause a compiler error, but only because I added explicit to the appropriate constructor. If I hadn't, a simple type or other oversight might let the compiler accept this line, even though it doesn't make much sense. The keyword ecplicit here helps us to make sanity checks at compile time.


P.S.: I just noticed you didn't actually talk about implict and explicit constructors using the explicit keyword, after all. I hope my response can still shed some light on a somewhat related area ...

I just remembered one other important property of initializer lists which could influence code semantics, so I thought I'd mention it.

Consider the following code:

class Base {
private:
  double x_;
  int y_;
public:
  int virtual MyMagicNumber() const;
  Base(double x) : x_(x) {
     y_ = MyMagicNumber();
  }
};

class derived : public Base {
private:
  int i_;
public:
   virtual int MyMagicNumber() const { return i_+1; }
   derived(int i) : Base((double(i)/2.0) {
      i_ = i; // version 1
   }
};
void Foo() {
   derived d(3);
}

Upon calling the constructor of derived, the following happens:

0. if no other instance of class derived has been created before, vtables will be created in memory
1. Memory gets allocated. This memory is uninitialized, it may not even be set to 0.
2. Base gets initialized, because it's on the initializer list
3. Base::x_ gets initialized to 1.5, because it is on the initializer list of Base::Base(double)
4. The code of Base::Base(double) gets executed
5. MyMgicNumber() gets called, via the vtable, where it gets resolved to derived::MyMagicNumber()
6. derived::MyMagicNumber() reads derived::i_ and then returns i_+1
7. Base::Base(double) initializes Base::y_ with the result from MyMagicNumber(). The constructor is done.
8. With Base::Base(double) done and nothing else on the initializer list, the code from derived::derived(int) finally gets executed
9. derived::i_ gets initialized to 3


So, the very last thing that happens during construction is the initialization of derived::i_, but some time before that, it already gets read! As a result, the state of Base::y_ is undefined! Of course, the true problem is that you shouldn't call virtual functions in your constructor code, but you can fix it, easily, by putting i on the initialization list as well:

derived(int i) i_(i), Base((double)i/2.0) {} // version 2

There. This moves the initialization of derived::i_ right up to position 2, and now the following initialization of Base::y_ will be well-defined!

In short, the initialization list is the only way to initialize class members before calling base class constructors! What you need to keep in mind is initialization order:
- First the initialization list, left to right (this may include direct base classes)
- Second any constructors for base classes not already listed on the initialization list (don't ask for virtual base classes, I'd need to look that up)
- Last the actual code in the constructor body