Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.
Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.
- In C++1998 there are 2 types of initialization: zero and default
- In C++2003 a 3rd type of initialization, value initialization was added.
Assume:
struct A { int m; }; // POD
struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m
In a C++98 compiler, the following should occur:
new A
- indeterminate value
new A()
- zero-initialize
new B
- default construct (B::m is uninitialized)
new B()
- default construct (B::m is uninitialized)
new C
- default construct (C::m is zero-initialized)
new C()
- default construct (C::m is zero-initialized)
In a C++03 conformant compiler, things should work like so:
new A
- indeterminate value
new A()
- value-initialize A, which is zero-initialization since it's a POD.
new B
- default-initializes (leaves B::m uninitialized)
new B()
- value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.
new C
- default-initializes C, which calls the default ctor.
new C()
- value-initializes C, which calls the default ctor.
So in all versions of C++ there's a difference between new A
and new A()
because A is a POD.
And there's a difference in behavior between C++98 and C++03 for the case new B()
.
This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.
Best Answer
I'd say the Rule of Three becomes the Rule of Three, Four and Five:
Note:
In particular, the following perfectly valid C++03 polymorphic base class:
Should be rewritten as follows:
A bit annoying, but probably better than the alternative (in this case, automatic generation of special member functions for copying only, without move possibility).
In contrast to the Rule of the Big Three, where failing to adhere to the rule can cause serious damage, not explicitly declaring the move constructor and move assignment operator is generally fine but often suboptimal with respect to efficiency. As mentioned above, move constructor and move assignment operators are only generated if there is no explicitly declared copy constructor, copy assignment operator or destructor. This is not symmetric to the traditional C++03 behavior with respect to auto-generation of copy constructor and copy assignment operator, but is much safer. So the possibility to define move constructors and move assignment operators is very useful and creates new possibilities (purely movable classes), but classes that adhere to the C++03 Rule of the Big Three will still be fine.
For resource-managing classes you can define the copy constructor and copy assignment operator as deleted (which counts as definition) if the underlying resource cannot be copied. Often you still want move constructor and move assignment operator. Copy and move assignment operators will often be implemented using
swap
, as in C++03. Talking aboutswap
; if we already have a move-constructor and move-assignment operator, specializingstd::swap
will become unimportant, because the genericstd::swap
uses the move-constructor and move-assignment operator if available (and that should be fast enough).Classes that are not meant for resource management (i.e., no non-empty destructor) or subtype polymorphism (i.e., no virtual destructor) should declare none of the five special member functions; they will all be auto-generated and behave correct and fast.