Constructor and its Types

Programming Language & Its Applications — C++ Constructs with Objects and Classes, NEC licence examination syllabus (Nepal Engineering Council).

Constructors and Their Types

A function that runs automatically when an object is born — the guarantee that no object exists in an invalid state.

🌍 Where this lives: constructors are why C++ has no "uninitialised object" bug class. In C you write struct FILE *f; and it holds garbage until you remember to set it; in C++ the constructor cannot be skipped, so std::string s; is always a valid empty string. This guarantee is the foundation of RAII — Resource Acquisition Is Initialisation — which is how C++ manages files, locks, sockets and memory without a garbage collector and without finally blocks. Python's __init__ and Java's constructors do the same job; what C++ adds is the matching destructor, which is the next topic and the other half of the idea. Search "RAII resource management C++"; it is arguably the single best idea in the language.

What defines a constructor

· NAME is exactly the class name · NO return type — not even void · called AUTOMATICALLY when an object is created · cannot be called explicitly like a normal function · can be OVERLOADED (several constructors, chosen by argument list) · can have DEFAULT ARGUMENTS · usually public; a private constructor is a deliberate technique (singletons, factories) class Point { int x, y; public: Point() : x(0), y(0) {} /* default */ Point(int a, int b) : x(a), y(b) {} /* parameterised */ Point(const Point &p) : x(p.x), y(p.y) {} /* copy */ }; If you write NO constructor at all, the compiler generates a default one. If you write ANY constructor, it stops doing so — so this breaks: class P { int x; public: P(int v):x(v){} }; P a; ✗ error: no default constructor P b(5); ✔

The four kinds

ctor_types.cpp

#include <iostream>
#include <string>

class Student {
    int         roll;
    std::string name;
    double      marks;
public:
    /* 1. DEFAULT — no arguments */
    Student() : roll(0), name("unknown"), marks(0.0) {
        std::cout << "  [default ctor]\n";
    }

    /* 2. PARAMETERISED */
    Student(int r, const std::string &n, double m)
        : roll(r), name(n), marks(m) {
        std::cout << "  [param ctor for " << n << "]\n";
    }

    /* 3. COPY — takes a const reference to its own type */
    Student(const Student &other)
        : roll(other.roll), name(other.name + " (copy)"),
          marks(other.marks) {
        std::cout << "  [copy ctor]\n";
    }

    /* 4. CONVERTING — one argument, enables implicit
          conversion unless marked explicit */
    Student(int r) : roll(r), name("roll only"), marks(0.0) {
        std::cout << "  [converting ctor]\n";
    }

    void show() const {
        std::cout << roll << " " << name << " " << marks << "\n";
    }
};

int main() {
    std::cout << "Student a;\n";              Student a;
    std::cout << "Student b(101,\"Ram\",87.5);\n";
                                    Student b(101,"Ram",87.5);
    std::cout << "Student c = b;\n";           Student c = b;
    std::cout << "Student d = 205;\n";         Student d = 205;

    a.show(); b.show(); c.show(); d.show();
    return 0;
}
Output:
Student a;
  [default ctor]
Student b(101,"Ram",87.5);
  [param ctor for Ram]
Student c = b;
  [copy ctor]
Student d = 205;
  [converting ctor]
0 unknown 0
101 Ram 87.5
101 Ram (copy) 87.5
205 roll only 0

Note `Student d = 205;` — an int silently became a Student. That is a CONVERTING constructor at work, and it is usually unwanted. Mark it explicit: explicit Student(int r) : ... {} Student d = 205; ✗ now an error Student d(205); ✔ still fine Student d{205}; ✔ still fine Rule: mark every single-argument constructor `explicit` unless you specifically want the implicit conversion. std::vector does exactly this — that is why std::vector<int> v = 10; is an error while std::vector<int> v(10); creates ten elements.

The initialiser list — not just style

Two ways that look equivalent but are not: Student(int r) { roll = r; } /* ASSIGNMENT */ Student(int r) : roll(r) { } /* INITIALISATION */ What actually happens with assignment: 1. roll is default-initialised (for a class member, its default constructor runs) 2. then the body ASSIGNS over it → two operations With the initialiser list: 1. roll is constructed directly with r → one operation For an int the difference is negligible. For a std::string member it is a wasted construction plus an assignment per object. THREE CASES WHERE THE LIST IS MANDATORY: 1. const members class C { const int id; C(int i) : id(i) {} }; ✔ C(int i) { id = i; } ✗ cannot assign to const 2. reference members class D { int &ref; D(int &r) : ref(r) {} }; ✔ only way 3. a base class or member with NO default constructor class E { Student s; E() : s(1,"x",0) {} }; ✔ required ORDER WARNING: members are initialised in DECLARATION order, NOT in the order you list them. class F { int a, b; public: F(int x) : b(x), a(b) {} /* BUG: a is initialised FIRST, using an uninitialised b */ }; Compile with -Wall and g++ warns: "field 'a' will be initialized after field 'b'". Always list members in declaration order.

init_list.cpp

#include <iostream>
#include <string>

class Tracer {
    std::string name;
public:
    Tracer(const std::string &n = "?") : name(n) {
        std::cout << "    ctor " << name << "\n";
    }
    Tracer& operator=(const Tracer &o) {
        std::cout << "    assign " << o.name
                  << " over " << name << "\n";
        name = o.name; return *this;
    }
};

class UsesAssignment {
    Tracer t;
public:
    UsesAssignment() {                /* body assignment */
        t = Tracer("real");           /* ctor + ctor + assign */
    }
};

class UsesInitList {
    Tracer t;
public:
    UsesInitList() : t("real") { }    /* ONE ctor */
};

class HasConstAndRef {
    const int   id;
    int        &ref;
public:
    HasConstAndRef(int i, int &r) : id(i), ref(r) {}
    void show() const {
        std::cout << "id=" << id << " ref=" << ref << "\n";
    }
};

int main() {
    std::cout << "UsesAssignment:\n";  UsesAssignment u1;
    std::cout << "UsesInitList:\n";    UsesInitList   u2;

    int external = 77;
    HasConstAndRef h(5, external);
    h.show();
    external = 88;
    std::cout << "after external=88 -> ";  h.show();
    return 0;
}
Output:
UsesAssignment:
    ctor ?
    ctor real
    assign real over ?
UsesInitList:
    ctor real
id=5 ref=77
after external=88 -> id=5 ref=88

Three operations versus one — visible in the output. And note the reference member tracks external: changing external to 88 changes what h.ref reads, because ref is an alias, not a copy.

Worked example — the copy constructor and shallow copy

shallow_deep.cpp

#include <iostream>
#include <cstring>

class BadString {
    char *buf;
public:
    BadString(const char *s) {
        buf = new char[std::strlen(s) + 1];
        std::strcpy(buf, s);
    }
    /* NO copy constructor -> the compiler generates one
       that copies the POINTER. Two objects, one buffer. */
    ~BadString() { delete[] buf; }
    void show() const { std::cout << buf << "\n"; }
    void poke(char c) { buf[0] = c; }
};

class GoodString {
    char *buf;
public:
    GoodString(const char *s) {
        buf = new char[std::strlen(s) + 1];
        std::strcpy(buf, s);
    }
    /* DEEP copy: allocate our own buffer */
    GoodString(const GoodString &o) {
        buf = new char[std::strlen(o.buf) + 1];
        std::strcpy(buf, o.buf);
    }
    ~GoodString() { delete[] buf; }
    void show() const { std::cout << buf << "\n"; }
    void poke(char c) { buf[0] = c; }
};

int main() {
    GoodString g1("hello");
    GoodString g2 = g1;      /* deep copy */
    g2.poke('J');
    std::cout << "g1: "; g1.show();
    std::cout << "g2: "; g2.show();

    /* BadString b1("hello"); BadString b2 = b1;
       b2.poke('J');   -> b1 ALSO changes (shared buffer)
       and at scope exit BOTH destructors delete[] the same
       pointer: DOUBLE FREE, undefined behaviour/crash. */
    return 0;
}
Output:
g1: hello
g2: Jello

SHALLOW copy (compiler-generated): b1.buf ──┐ ├──> ["hello\0"] one buffer b2.buf ──┘ Consequences: · modifying one appears to modify both · both destructors delete the same memory → DOUBLE FREE → crash or heap corruption DEEP copy (hand-written): g1.buf ───> ["hello\0"] g2.buf ───> ["hello\0"] two buffers Independent objects, each destructor frees its own. THE RULE OF THREE: if a class needs any one of · a destructor · a copy constructor · a copy assignment operator it almost certainly needs ALL THREE. Managing a raw resource means all three must agree on ownership. C++11 extends this to the RULE OF FIVE (adding the move constructor and move assignment). And the modern advice is the RULE OF ZERO: use std::string, std::vector and std::unique_ptr so you need to write NONE of them.

The compiler-generated copy constructor is not wrong — it is right for the majority of classes, which hold values rather than resources. It becomes catastrophic precisely when a member is a raw pointer that the object owns. That is the single distinction to look for: does this class own something that must be freed exactly once?

When copy constructors are called

Four situations, some non-obvious: 1. explicit copy initialisation Student b = a; or Student b(a); 2. passing an object BY VALUE void f(Student s); f(a); ← copy made 3. returning an object BY VALUE Student g() { Student s; return s; } ← copy in principle; usually ELIDED (see below) 4. an element being inserted into a container v.push_back(a); NOT a copy constructor: Student b; b = a; ← that is copy ASSIGNMENT, a different function COPY ELISION: since C++17 the compiler is REQUIRED to skip the copy in case 3 for a temporary, and it usually skips it for a named local too (NRVO). So Student g() { return Student(1,"x",0); } Student s = g(); constructs the object exactly ONCE, directly in s. Do not "optimise" this by returning a pointer or reference — you would make it slower and unsafe.

🌍 Go further: the Rule of Three is really about ownership, which is the central problem in systems programming. C++ solved it with smart pointers (unique_ptr for single ownership, shared_ptr for reference counting); Rust solved it by making ownership a checked property of the type system, so the double-free above is a compile error rather than a crash. Reading about Rust's borrow checker after understanding this page is genuinely illuminating — it is the same problem with a different answer. Search "rule of zero smart pointers" for the modern C++ approach.

💡 Exam angle: list the four constructor types (default, parameterised, copy, converting) with a code example of each — this is a guaranteed question. Know that the compiler stops generating a default constructor once you write any constructor. The initialiser list and its three mandatory cases (const members, reference members, members without a default constructor) is high-value, as is the declaration-order gotcha. Shallow versus deep copy with the double-free consequence, plus the Rule of Three, is the standard long-answer question.

Syllabus points

Default, parameterized, copy constructor

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.