What is Programmer supplied default constructor and a system supplied constructor in C plus plus?

Answer 1

A programmer-supplied default constructor is one that you, the programmer, explicitly implements in a class definition. A system-supplied constructor is one that is generated for you automatically by the compiler and are known as compiler-generated constructors for that reason.

If you do not define any constructors, the compiler will automatically generate 3 constructors for you:

1. a default constructor
2. a copy constructor
3. a move constructor

The default constructor is a constructor that requires no arguments. The compiler-generated default constructor invokes the default constructor for each data member but primitive data type members do not have constructors and are therefore left in an uninitialised state unless we use inline initialisation.

The copy constructor accepts a constant l-value reference to an existing object of the same type. Data members are initialised using member-wise copy semantics. Uninitialised data members remain uninitialised in both objects.

The move constructor accepts a non-constant r-value reference to an existing object of the same type. Individual data members are initialised using move semantics where available, otherwise copy semantics are used (as per the copy constructor).

If you define any constructor, the compiler will not generate a default constructor unless you define your own. The compiler-generated copy and move constructors are always generated unless you provide your own implementation for one or both.

It is considered good practice to explicitly declare all three constructors in order to make it clear to the class maintainer whether constructors are compiler-generated, user-defined, or deleted. For example:

class A {

public:

A ()=default;

A (const A&)=delete;

A (A&&);

// ...

};

A::A (A&&) {

// ...

}

In the above example, the default constructor is compiler-generated (=default), the copy constructor is disabled (=delete) and the move constructor is user-defined.

In most cases, the compiler-generated constructors will suffice, but if you need to provide a non-default constructor it's easy to forget that the default constructor will not be generated. Therefore get into the habit of being explicit. In the majority of cases, your class declarations will take the following form:

class A { public:

A ()=default;

A (const A&)=default;

A (A&&)=default;

// ...

};

If you genuinely do not need a default constructor then declare it with the =delete postscript and provide your own non-default constructor (all classes must have at least one constructor that is neither a copy or a move constructor). Note that a user-defined constructor that takes one or more arguments where every argument has a default value is also a default constructor.

In addition to copy and move constructors, the compiler also generates corresponding copy and move assignment operators as well as a destructor. Treat all compiler-generated code as a unified set; in most cases your classes will have the following form:

class A {

public:

A ()=default;

~A ()=default;

A (const A&)=default;

A& operator= (const A&)=default;

A (A&&)=default;

A& operator= (A&&)=default;

// ...

};

There will be cases where the compiler-generated behaviour is undesirable. For instance, if your class acquires a resource, you will want to override all compiler-generated code with your own implementations in order to manage that resource. However, if you use smart pointers or resource handles rather than "naked" pointers, the compiler-generated behaviour provides exactly the semantic you want. The only time you really need to override that behaviour is when defining your own resource handles or smart pointers.

Another reason to override the default construction behaviour is when you need to perform additional tasks that are not provided by the default semantics, such as when testing a class invariant. The copy/move constructors and assignment operators never need to test an invariant so the default semantic usually suffices, but all other constructors, assignment operators and other mutators (setters) must. Ideally, every class should have one and only one invariant at most. A string class, for instance, has an invariant in that it must always refer to a null-terminated string, even when the string is empty. By delegating that invariant to the string class itself, other classes can embed string objects without having to worry about the string invariant, they need only worry about their own invariant (if any).