Constructor Chaining in C++: How Delegating Constructors Work

By the end of this page, you will understand how constructor chaining works in C++, when it is supported, and how to share initialization logic safely. You will learn about delegating constructors, initializer lists, older workarounds used before modern C++, and common mistakes beginners make when trying to call one constructor from another.

In C++, constructor chaining is usually called delegating constructors.

A delegating constructor is a constructor that forwards construction to another constructor in the same class.

In modern C++ (C++11 and later), this is supported directly:

class Test {
public:
    Test() {
        DoSomething();
    }

    Test(int count) : Test() {
        DoSomethingWithCount(count);
    }

    Test(int count, const std::string& name) : Test(count) {
        DoSomethingWithName(name);
    }

private:
    void DoSomething() {}
    void DoSomethingWithCount(int) {}
    void DoSomethingWithName(const std::string&) {}
};

This is the C++ equivalent of C# constructor chaining.

Why this matters

Constructors often need to do shared setup:

• initialize member variables
• validate input
• open resources
• avoid duplicated code

Think of constructing a C++ object like assembling a machine at a factory.

• A constructor is the assembly process.
• A delegating constructor says: "Start with the basic assembly process first, then add extra parts."
• A failed attempt like calling Test() inside another constructor is like accidentally building a different machine on the side, not continuing work on the current one.

So in C++:

• Test() : Test(other) means build this object by first using another constructor.
• Test(); inside the constructor body means make a temporary separate object.

That difference is one of the most important ideas to remember.

Core syntax

In C++11 and later, you delegate to another constructor in the member initializer list:

ClassName(parameters) : ClassName(other_arguments) {
    // extra work here
}

Example

#include <iostream>
#include <string>

class Test {
public:
    Test() {
        std::cout << "Base setup\n";
    }

    Test(int count) : Test() {
        std::cout << "Count: " << count << "\n";
    }

    Test(int count, const std::string& name) : Test(count) {
        std::cout << "Name: " << name << "\n";
    }
};

int main() {
    Test a;
    std::cout << "---\n";
    Test b(3);
    std::cout << "---\n";
    Test ;
}

Consider this example:

#include <iostream>
#include <string>

class Test {
public:
    Test() {
        std::cout << "1. Default constructor\n";
    }

    Test(int count) : Test() {
        std::cout << "2. Count constructor: " << count << "\n";
    }

    Test(int count, const std::string& name) : Test(count) {
        std::cout << "3. Name constructor: " << name << "\n";
    }
};

int main() {
    Test t(10, "Sam");
}

What happens?

When this line runs:

Test t(10, "Sam");

C++ follows these steps:

1. It chooses the constructor .

Constructor chaining is useful whenever objects have multiple ways to be created but still need common setup.

Common examples

Configuration objects

class Config {
public:
    Config() : host("localhost"), port(8080) {}
    Config(int p) : Config() { port = p; }

private:
    std::string host;
    int port;
};

Use case:

• default development settings
• allow overriding only one value

File or resource wrappers

A class might always need base validation or default state before opening a file with different options.

Logging classes

A logger may always initialize a default log level, while other constructors add file names, prefixes, or formatting options.

API clients

An HTTP client may start with default headers and timeout values, while additional constructors supply a token, base URL, or retry settings.

Game objects or UI components

Objects may always need default position, ID, or style settings, while overloaded constructors customize size, label, or behavior.

In real projects, developers use constructor chaining to keep initialization consistent and avoid copy-paste logic.

Common patterns

1. Default values plus overrides

A base constructor sets safe defaults, and other constructors override only what changes.

class ServerOptions {
public:
    ServerOptions() : port(80), useSsl(false) {}
    ServerOptions(int p) : ServerOptions() { port = p; }
    ServerOptions(int p, bool ssl) : ServerOptions(p) { useSsl = ssl; }

private:
    int port;
    bool useSsl;
};

2. Input validation in one place

One constructor can normalize or validate values before shared state is used.

3. Guarding against duplication

Instead of repeating the same setup in several constructors, delegate to a single constructor that owns the common initialization.

4. Combining with initializer lists

In C++, member initialization should usually happen in initializer lists, not by assigning inside the constructor body.

class User {
:
    () : (), () {}
    ( std::string& n) : () { name = n; }

:
    std::string name;
     age;
};

1. Calling the constructor like a normal function

Broken example:

class Test {
public:
    Test() {}

    Test(int count) {
        Test(); // wrong
    }
};

Problem

This creates a temporary Test object. It does not initialize the current object.

Fix

Use delegation in the initializer list:

class Test {
public:
    Test() {}
    Test(int count) : Test() {}
};

2. Trying to use this() like in C#

Broken example:

class Test {
public:
    Test() {}

    Test(int count) : this() { // wrong
    }
};

Problem

Delegating constructor vs helper function

Constructor chaining in C++

Modern syntax

class Test {
public:
    Test() {}
    Test(int x) : Test() {}
    Test(int x, const std::string& name) : Test(x) {}
};

Rules

• Use : ClassName(...) to delegate.
• Delegation happens in the initializer list.
• Only one constructor runs first as the target.
• Add extra work in the constructor body after delegation.
• Requires C++11 or later.

Do not do this

Test() ;          // declaration, not chaining
Test();           // creates a temporary object in a constructor body
this->Test();     // invalid
:this();          // C# style, not C++

Best practices

• Put common setup in one constructor.
• Prefer initializer lists for member initialization.
• Avoid duplicated constructor logic.
• Avoid cyclic delegation.

Pre-C++11 fallback

Can I call one constructor from another in C++?

Yes, in C++11 and later you can use delegating constructors with the syntax : ClassName(...).

Why does calling Test() inside a constructor not work?

Because it creates a separate temporary object instead of reusing the current object.

Is this() valid in C++ like it is in C#?

No. C++ constructor delegation uses the class name, not this().

Do delegating constructors work in old C++ versions?

No. They were added in C++11. In older code, use a helper function or redesign the constructors.

Should I use a helper function instead of constructor chaining?

Use a helper function only when delegating constructors are unavailable or when the shared code is not true initialization logic.

Can constructor delegation be recursive?

No. Cyclic delegation is invalid and must be avoided.

Should I initialize members in the body or the initializer list?

Prefer the initializer list whenever possible. It is usually more efficient and idiomatic in C++.

• Constructor overloading — constructor chaining is usually used when a class has multiple constructors.
• Member initializer lists — delegating constructors use initializer-list syntax.
• Object lifetime — understanding when and how objects are created explains why temporary objects are different from this.
• Default constructors — many constructor chains start from a default constructor.
• Copy constructors — another special kind of constructor in C++ with its own rules.
• Move constructors — important for modern C++ object creation and resource management.
• RAII — constructors often acquire resources, so correct initialization is essential.
• Factory functions — an alternative when creation logic becomes more complex than constructor chaining should handle.