The new syntax "= default" in C++11

Question

I don't understand why would I ever do this:

struct S { 
    int a; 
    S(int aa) : a(aa) {} 
    S() = default; 
};

Why not just say:

S() {} // instead of S() = default;

why bring in a new syntax for that?

Answer 1

A defaulted default constructor is specifically defined as being the same as a user-defined default constructor with no initialization list and an empty compound statement.

§12.1/6 [class.ctor] A default constructor that is defaulted and not defined as deleted is implicitly defined when it is odr-used to create an object of its class type or when it is explicitly defaulted after its first declaration. The implicitly-defined default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with no ctor-initializer (12.6.2) and an empty compound-statement. [...]

However, while both constructors will behave the same, providing an empty implementation does affect some properties of the class. Giving a user-defined constructor, even though it does nothing, makes the type not an aggregate and also not trivial. If you want your class to be an aggregate or a trivial type (or by transitivity, a POD type), then you need to use = default.

§8.5.1/1 [dcl.init.aggr] An aggregate is an array or a class with no user-provided constructors, [and...]

§12.1/5 [class.ctor] A default constructor is trivial if it is not user-provided and [...]

§9/6 [class] A trivial class is a class that has a trivial default constructor and [...]

To demonstrate:

#include <type_traits>

struct X {
    X() = default;
};

struct Y {
    Y() { };
};

int main() {
    static_assert(std::is_trivial<X>::value, "X should be trivial");
    static_assert(std::is_pod<X>::value, "X should be POD");
    
    static_assert(!std::is_trivial<Y>::value, "Y should not be trivial");
    static_assert(!std::is_pod<Y>::value, "Y should not be POD");
}

Additionally, explicitly defaulting a constructor will make it constexpr if the implicit constructor would have been and will also give it the same exception specification that the implicit constructor would have had. In the case you've given, the implicit constructor would not have been constexpr (because it would leave a data member uninitialized) and it would also have an empty exception specification, so there is no difference. But yes, in the general case you could manually specify constexpr and the exception specification to match the implicit constructor.

Using = default does bring some uniformity, because it can also be used with copy/move constructors and destructors. An empty copy constructor, for example, will not do the same as a defaulted copy constructor (which will perform member-wise copy of its members). Using the = default (or = delete) syntax uniformly for each of these special member functions makes your code easier to read by explicitly stating your intent.

Answer 2

I have an example that will show the difference:

#include <iostream>

using namespace std;
class A 
{
public:
    int x;
    A(){}
};

class B 
{
public:
    int x;
    B()=default;
};


int main() 
{ 
    int x = 5;
    new(&x)A(); // Call for empty constructor, which does nothing
    cout << x << endl;
    new(&x)B; // Call for default constructor
    cout << x << endl;
    new(&x)B(); // Call for default constructor + Value initialization
    cout << x << endl;
    return 0; 
} 

Output:

5
5
0

As we can see the call for empty A() constructor does not initialize the members, while B() does it.

Answer 3

n2210 provides some reasons:

The management of defaults has several problems:

• Constructor definitions are coupled; declaring any constructor suppresses the default constructor.
• The destructor default is inappropriate to polymorphic classes, requiring an explicit definition.
• Once a default is suppressed, there is no means to resurrect it.
• Default implementations are often more efficient than manually specified implementations.
• Non-default implementations are non-trivial, which affects type semantics, e.g. makes a type non-POD.
• There is no means to prohibit a special member function or global operator without declaring a (non-trivial) substitute.

---

type::type() = default;
type::type() { x = 3; }

In some cases, the class body can change without requiring a change in member function definition because the default changes with declaration of additional members.

See Rule-of-Three becomes Rule-of-Five with C++11?:

Note that move constructor and move assignment operator won't be generated for a class that explicitly declares any of the other special member functions, that copy constructor and copy assignment operator won't be generated for a class that explicitly declares a move constructor or move assignment operator, and that a class with a explicitly declared destructor and implicitly defined copy constructor or implicitly defined copy assignment operator is considered deprecated

Answer 4

It's a matter of semantics in some cases. It's not very obvious with default constructors, but it becomes obvious with other compiler-generated member functions.

For the default constructor, it would have been possible to make any default constructor with an empty body be considered a candidate for being a trivial constructor, same as using =default. After all, the old empty default constructors were legal C++.

struct S { 
  int a; 
  S() {} // legal C++ 
};

Whether or not the compiler understands this constructor to be trivial is irrelevant in most cases outside of optimizations (manual or compiler ones).

However, this attempt to treat empty function bodies as "default" breaks down entirely for other types of member functions. Consider the copy constructor:

struct S { 
  int a; 
  S() {}
  S(const S&) {} // legal, but semantically wrong
};

In the above case, the copy constructor written with an empty body is now wrong. It's no longer actually copying anything. This is a very different set of semantics than the default copy constructor semantics. The desired behavior requires you to write some code:

struct S { 
  int a; 
  S() {}
  S(const S& src) : a(src.a) {} // fixed
};

Even with this simple case, however, it's becoming much more of a burden for the compiler to verify that the copy constructor is identical to the one it would generate itself or for it to see that the copy constructor is trivial (equivalent to a memcpy, basically). The compiler would have to check each member initializer expression and ensure it's identical to the expression to access the source's corresponding member and nothing else, make sure no members are left with non-trivial default construction, etc. It's backwards in a way of the process the compiler would use to verify that it's own generated versions of this function is trivial.

Consider then the copy assignment operator which can get even hairier, especially in the non-trivial case. It's a ton of boiler-plate that you don't want to have to write for many classes but you're be forced to anyway in C++03:

struct T { 
  std::shared_ptr<int> b; 
  T(); // the usual definitions
  T(const T&);
  T& operator=(const T& src) {
    if (this != &src) // not actually needed for this simple example
      b = src.b; // non-trivial operation
    return *this;
};

That is a simple case, but it's already more code than you would ever want to be forced to write for such a simple type as T (especially once we toss move operations into the mix). We can't rely on an empty body meaning "fill in the defaults" because the empty body is already perfectly valid and has a clear meaning. In fact, if the empty body were used to denote "fill in the defaults" then there'd be no way to explicitly make a no-op copy constructor or the like.

It's again a matter of consistency. The empty body means "do nothing" but for things like copy constructors you really don't want "do nothing" but rather "do all the things you'd normally do if not suppressed." Hence =default. It's necessary for overcoming suppressed compiler-generated member functions like copy/move constructors and assignment operators. It's then just "obvious" to make it work for the default constructor as well.

It might have been nice to make default constructor with empty bodies and trivial member/base constructors also be considered trivial just as they would have been with =default if only to make older code more optimal in some cases, but most low-level code relying on trivial default constructors for optimizations also relies on trivial copy constructors. If you're going to have to go and "fix" all your old copy constructors, it's really not much of a stretch to have to fix all your old default constructors, either. It's also much clearer and more obvious using an explicit =default to denote your intentions.

There are a few other things that compiler-generated member functions will do that you'd have to explicitly make changes to support, as well. Supporting constexpr for default constructors is one example. It's just easier mentally to use =default than having to mark up functions with all the other special keywords and such that are implied by =default and that was one of the themes of C++11: make the language easier. It's still got plenty of warts and back-compat compromises but it's clear that it's a big step forward from C++03 when it comes to ease-of-use.

Answer 5

Due to the deprecation of std::is_pod and its alternative std::is_trivial && std::is_standard_layout, the snippet from @JosephMansfield 's answer becomes:

#include <type_traits>

struct X {
    X() = default;
};

struct Y {
    Y() {}
};

int main() {
    static_assert(std::is_trivial_v<X>, "X should be trivial");
    static_assert(std::is_standard_layout_v<X>, "X should be standard layout");

    static_assert(!std::is_trivial_v<Y>, "Y should not be trivial");
    static_assert(std::is_standard_layout_v<Y>, "Y should be standard layout");
}

Note that the Y is still of standard layout.

Answer 6

There is a signicant difference when creating an object via new T(). In case of defaulted constructor aggregate initialization will take place, initializing all member values to default values. This will not happen in case of empty constructor. (won't happen with new T either)

Consider the following class:

struct T {
    T() = default;
    T(int x, int c) : s(c) {
        for (int i = 0; i < s; i++) {
            d[i] = x;
        }
    }
    T(const T& o) {
        s = o.s;
        for (int i = 0; i < s; i++) {
            d[i] = o.d[i];
        }
    }
    void push(int x) { d[s++] = x; }
    int pop() { return d[--s]; }

private:
    int s = 0;
    int d[1<<20];
};

new T() will initialize all members to zero, including the 4 MiB array (memset to 0 in case of gcc). This is obviously not desired in this case, defining an empty constructor T() {} would prevent that.

In fact I tripped on such case once, when CLion suggested to replace T() {} with T() = default. It resulted in significant performance drop and hours of debugging/benchmarking.

So I prefer to use an empty constructor after all, unless I really want to be able to use aggregate initialization.

Answer 7

It will be good to clarify the behavior pointed out by trozen's answer and Slavenskij's answer.

The empty default constructor like Widget() {}; is seen as a user defined default constructor, while Widget() = default; is not. This leads to default initialization in the former case, while value initialization in the latter, in definitions involving the form Widget w = new Widget(), Widget w{} etc.

See here for more details, where you will also come to know that the location of = default; matters to obtain a compiler generated default constructor.