Constructors: public, sab jaanti hai ?
BACK TO RECORDS

Constructors: public, sab jaanti hai ?

April 1, 2026C++ / Object Oriented Programming / Constructors
Constructors, Ego, and a Lesson That Stayed

Constructors: public, sab jaanti hai?

Story Time

This is a real incident from my 5th semester when my professor Sanjeet Kumar was teaching Android Programming.

Yes, I didn’t really like development. I was mostly doing competitive programming.

But there were two reasons I attended those classes:

  • He is my favorite teacher
  • I love OOP

At that time, I had already become a 4-star on CodeChef, Codeforces hustle was still going on, and yes .... I had also started trying to impress the JavaScript girl from my class by end of 4th Semester.

During one of the classes, I was again trying to be a bit annoying.

Android Programming class discussion

And as expected, sir decided to humble me again.

(He loves doing that. I think he does this mostly to his favorite students.)

He said during the class:

"Raj, not everything needs to be public… keep your personal life private."

The JavaScript girl understood the line… smiled… and said:

"But sir, constructors are always public."

Sir turned towards me and asked:

"Raj, does constructor need to be private?"

I confidently replied:

"Constructors need to be public. Books use constructors in public."

Sir paused… and said:

"I don’t think so… Constructors can be private.
And yes, they don’t return values... but there are ways to make it feel like they do."

That day, I learned something I want to share. And that’s when the real lesson began.

1. What books usually show

Most tutorials start like this:


class Car
{
public:
    Car() {
        cout << "Car created\n";
    }
};

Then objects are created:

Car c;

So beginners conclude:

CONSTRUCTOR MUST BE PUBLIC.

But the C++ standard never says this.

2. Constructors Can Be Private


class Car
{
private:
    Car() {
        cout << "Car created\n";
    }
};

int main()
{
    Car c;   // ❌ ERROR
}

Compiler error happens because main cannot access a private constructor.

This means object creation itself is controlled.

3. Why Would Anyone Do This?

Case 1: Singleton Pattern

Only one object allowed.


class Database
{
private:
    Database(){}

public:
    static Database& getInstance()
    {
        static Database obj;
        return obj;
    }
};

Now object creation is restricted.

Database& db = Database::getInstance();

You cannot do

Database db; // impossible

Case 2: Factory Pattern

Sometimes objects must be created through a function.


class Logger
{
private:
    Logger(){}

public:
    static Logger create()
    {
        return Logger();
    }
};

This lets the class control initialization logic.

Case 3: Static-Only Classes

Sometimes a class is just a namespace with functions.


class MathUtils
{
private:
    MathUtils() = delete;

public:
    static int add(int a, int b)
    {
        return a + b;
    }
};

Now no object can ever exist.

4. The Real Rule

C++ only requires that:

A constructor must be accessible from the place where the object is created.

That's it.

So it can be:

  • public
  • protected
  • private
  • deleted

5. The Subtle Design Lesson

When constructors are public, anyone can create objects.

When they are private/protected:

You control object creation.

That’s encapsulation at the object-creation level.

Why Constructors Don’t Have a Return Type

In C++, a constructor does not return anything — not even void.

You cannot write:


class A {
public:
    int A() { }   // ❌ illegal
};

because constructors are not normal functions.

The real reason

When an object is created:

A obj(5);

two things happen internally:

1️⃣ Memory is allocated for the object

2️⃣ Constructor initializes that memory

So the constructor does not produce an object.

The object already exists in memory.

The constructor simply initializes it using the this pointer.

Conceptual Model


void A_constructor(A* this, int x)
{
    this->value = x;
}

Deep Insight

The constructor does return something....just not explicitly.

It returns a fully initialized object through the this pointer.

What Happens Internally (GCC View)

Suppose you write:


class A {
public:
    int x;

    A(int v) {
        x = v;
    }
};

Object creation:

A obj(5);

GCC roughly generates something like:

call _ZN1AC1Ei

which demangles to:

A::A(int)

And internally it behaves like:

A::A(A* this, int v)

So the object pointer (this) is the real output channel.

Can We Force a Constructor to Return Something?

Short answer:

❌ No. The language forbids it.

You cannot write:


class A {
public:
    A() {
        return something; // ❌ illegal
    }
};

The compiler will reject it.

Even the standard explicitly disallows returning values from constructors.

But There Are Clever Workarounds

Even though constructors cannot return values, design patterns simulate it.

1️⃣ Factory Functions


class A {
private:
    int x;

    A(int v) : x(v) {}

public:
    static A create(int v)
    {
        return A(v);
    }
};

Usage:

A obj = A::create(10);

2️⃣ Builder Pattern


class User {
public:
    std::string name;
    int age;

    User(std::string n, int a) : name(n), age(a) {}
};

Factory:


User createAdmin()
{
    return User("Admin", 100);
}

3️⃣ operator new Trick (Advanced)

Technically you can customize memory allocation:


void* operator new(size_t size)
{
    cout << "Allocating memory\n";
    return malloc(size);
}

Even here:

  • operator new returns memory
  • constructor still returns nothing

Final Insight

C++ separates:

  • Memory allocation → operator new
  • Initialization → constructor

This is why C++ can operate so close to hardware.


The real lesson: what books simplify is not always the full truth.