5

Some of my colleagues prefer to explicitly initialize std::auto_ptr to 0 in constructor initialization list, but it will be initialized to 0 in it's constructor without any explicit initialization. So is there any reason to do it?

#include <memory>

class A
{
  A() : SomePtr(0)
  {
  }

private:
  std::auto_ptr<SomeType> SomePtr;
};
ks1322
  • 33,961
  • 14
  • 109
  • 164
  • possible duplicate of [Is there any need to assign null pointer to std::auto_ptr](http://stackoverflow.com/questions/3664145/is-there-any-need-to-assign-null-pointer-to-stdauto-ptr) – Alex B Oct 06 '11 at 09:24

3 Answers3

9

No, the default constructor of std::auto_ptr does exactly that, so doing it explicitly is not necessary. In any case, it's a matter of style and you should be consistent. For instance, would you explicitly call the default constructor of a member vector in the constructor initialization list?

As a side note, std::auto_ptr is deprecated in the upcoming standard

Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434
0

Psychology.

For built-in types, you probably already know they are uninitialized unless you do so explicitly. For classes, this is not the case.

A strive to consistency results in explicit initialization everywhere. This allows you to forget if A::SomePtr is a built-in or a class type. Pretty useless, imho, since the amount of built-in types is quite limited.

xtofl
  • 40,723
  • 12
  • 105
  • 192
0

One reason maybe clarity, but that should be the only one. I myself prefer not to write unneccessary intialization, especially if that completely spares me from writing a default constructor for the surrounding class and just let the compiler do its job. Whereas it's merely a matter of style, I think too much over-paranoia does even harm the clarity of the code.

Christian Rau
  • 45,360
  • 10
  • 108
  • 185