Dynamic Memory Allocation for Objects

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

Dynamic Memory Allocation for Objects

new and delete — allocation that also runs constructors, unlike malloc which does not.

🌍 Where this lives: every object whose lifetime you cannot predict at compile time lives on the heap — the nodes of a linked list, the widgets in a window, the entities in a game, the rows returned by a database query. And every memory leak you have ever heard about is a heap allocation whose delete never ran. When a browser tab slowly consumes 4 GB, that is this topic failing. Modern C++ answers it with smart pointers, and Java/Python answer it with garbage collection — but both are managing exactly the memory you are about to allocate by hand. Search "valgrind memory leak detection"; running your own program under it once is genuinely eye-opening.

new and delete versus malloc and free

malloc/free (C) new/delete (C++) ──────────────────────────────────────────────────────── is a library function LANGUAGE OPERATOR size you compute it computed automatically returns void*, needs a cast the correct type constructor NOT called CALLED destructor NOT called (free) CALLED (delete) on failure returns NULL THROWS std::bad_alloc array form same function separate new[]/delete[] overloadable no yes (per class) /* C style — WRONG for a class with a constructor */ Student *s = (Student*)malloc(sizeof(Student)); → raw bytes; roll, name, marks are GARBAGE; std::string member is not constructed → using it is undefined behaviour free(s); → destructor never runs → the string's buffer LEAKS /* C++ style */ Student *s = new Student(101, "Ram", 87.5); → allocates AND constructs delete s; → destructs AND deallocates NEVER MIX THEM: new ... free() ✗ malloc ... delete ✗ new[] ... delete ✗ new ... delete[] ✗ Each pair must match exactly.

new_delete.cpp

#include <iostream>
#include <string>

class Student {
    int         roll;
    std::string name;
public:
    Student(int r = 0, std::string n = "unknown")
        : roll(r), name(std::move(n)) {
        std::cout << "  ctor " << roll << " " << name << "\n";
    }
    ~Student() { std::cout << "  dtor " << roll << "\n"; }
    void show() const {
        std::cout << "  " << roll << " " << name << "\n";
    }
};

int main() {
    /* single object */
    Student *s = new Student(101, "Ram Bahadur");
    s->show();
    delete s;
    s = nullptr;

    /* array — each element default-constructed */
    std::cout << "new Student[3]:\n";
    Student *arr = new Student[3];
    arr[0] = Student(201, "Sita");
    std::cout << "delete[]:\n";
    delete[] arr;

    /* array with initialiser list (C++11) */
    std::cout << "initialised array:\n";
    Student *b = new Student[2]{ {301,"Hari"}, {302,"Gita"} };
    b[0].show(); b[1].show();
    delete[] b;
    return 0;
}
Output:
  ctor 101 Ram Bahadur
  101 Ram Bahadur
  dtor 101
new Student[3]:
  ctor 0 unknown
  ctor 0 unknown
  ctor 0 unknown
  ctor 201 Sita
  dtor 201
delete[]:
  dtor 0
  dtor 0
  dtor 0
initialised array:
  ctor 301 Hari
  ctor 302 Gita
  301 Hari
  302 Gita
  dtor 302
  dtor 301

Note the ctor 201 Sita / dtor 201 pair in the middle: arr[0] = Student(201,"Sita") builds a temporary, copy-assigns it into arr[0], then destroys the temporary. And delete[] runs three destructors while the reversed order (302 before 301) confirms arrays are destroyed back to front.

Stack versus heap

STACK HEAP ────────────────────────────────────────────────────────── allocated by the compiler you, with new freed by automatic, at scope you, with delete exit size small (1-8 MB total) large (GBs) speed very fast — one slower — the register adjustment allocator searches for a free block lifetime tied to scope until you delete fragmentation none yes, over time overflow signal stack overflow crash bad_alloc exception void f() { Student a(1,"stack"); ← stack: dies at } Student *b = new Student(2,"heap"); ← heap: lives until delete delete b; } WHEN TO USE THE HEAP: · the object must outlive the function that made it · the size is unknown until runtime · the object is large (a 2 MB array would overflow the stack; the heap handles it easily) · you need polymorphism through a base pointer · the count is decided at runtime (linked list nodes) OTHERWISE PREFER THE STACK. It is faster, cannot leak, and cleans up on exceptions automatically.

stack_heap.cpp

#include <iostream>

int main() {
    /* This would very likely CRASH — 8 MB on an 8 MB stack */
    /* double big[1000000]; */

    /* the heap handles it comfortably */
    double *big = new double[1000000];
    for (long i = 0; i < 1000000; i++) big[i] = i * 0.5;
    std::cout << "allocated "
              << 1000000 * sizeof(double) / 1048576.0
              << " MB on the heap\n";
    std::cout << "big[999999] = " << big[999999] << "\n";
    delete[] big;

    /* runtime-determined size */
    int n;
    std::cout << "how many? ";
    if (!(std::cin >> n) || n <= 0) return 1;
    int *a = new int[n];
    for (int i = 0; i < n; i++) a[i] = (i+1) * (i+1);
    for (int i = 0; i < n; i++) std::cout << a[i] << " ";
    std::cout << "\n";
    delete[] a;
    return 0;
}
Output:
allocated 7.62939 MB on the heap
big[999999] = 499999.5
how many? 6
1 4 9 16 25 36

Checking the numbers: 1,000,000 doubles × 8 bytes = 8,000,000 bytes 8,000,000 / 1,048,576 = 7.62939 MB ✔ big[999999] = 999999 × 0.5 = 499999.5 ✔ And that 7.63 MB is why the stack version crashes: the default thread stack on Linux is 8 MB TOTAL, shared with every frame already on it. The heap has no such limit short of physical memory. Check your own limit with: ulimit -s (in KB)

Worked example — leaks, and how to make them impossible

leaks.cpp

#include <iostream>
#include <memory>
#include <stdexcept>

class Resource {
    int id;
public:
    Resource(int i) : id(i) {
        std::cout << "  acquire " << id << "\n";
    }
    ~Resource() { std::cout << "  release " << id << "\n"; }
    void use() const { std::cout << "  using " << id << "\n"; }
};

/* LEAK 1: early return skips the delete */
void leak_early(bool bail) {
    Resource *r = new Resource(1);
    if (bail) return;              /* LEAKED */
    r->use();
    delete r;
}

/* LEAK 2: an exception skips the delete */
void leak_throw() {
    Resource *r = new Resource(2);
    throw std::runtime_error("boom");   /* LEAKED */
    delete r;                            /* never reached */
}

/* FIX: unique_ptr releases in ITS destructor, which runs
   on every exit path including exceptions */
void safe(bool bail) {
    auto r = std::make_unique<Resource>(3);
    if (bail) return;              /* released */
    r->use();
    throw std::runtime_error("boom");   /* released */
}

int main() {
    std::cout << "leak_early(true):\n";  leak_early(true);
    std::cout << "leak_throw():\n";
    try { leak_throw(); } catch (...) { std::cout << "  caught\n"; }

    std::cout << "safe(true):\n";        safe(true);
    std::cout << "safe(false):\n";
    try { safe(false); } catch (...) { std::cout << "  caught\n"; }
    return 0;
}
Output:
leak_early(true):
  acquire 1
                       <-- no "release 1": LEAKED
leak_throw():
  acquire 2
  caught
                       <-- no "release 2": LEAKED
safe(true):
  acquire 3
  release 3            <-- released on early return
safe(false):
  acquire 3
  using 3
  release 3            <-- released during unwinding
  caught

The missing "release" lines ARE the leak, visible in output. Why unique_ptr wins: it is a stack object holding a heap pointer. The stack object's destructor is guaranteed to run on every exit path — normal return, early return, break, or exception unwinding — and that destructor calls delete. std::unique_ptr<T> single owner, cannot be copied, zero overhead vs a raw pointer std::shared_ptr<T> reference-counted, multiple owners, costs an atomic counter std::weak_ptr<T> a non-owning observer; breaks the reference cycles that leak shared_ptr Prefer make_unique / make_shared over raw new: auto p = std::make_unique<Student>(101, "Ram"); It is exception-safe in argument evaluation and mentions the type once instead of twice. THE MODERN RULE: in application code, you should almost never write `new` or `delete`. Use containers (std::vector, std::string) and smart pointers. The raw forms remain essential to KNOW — you will read older code, implement data structures, and answer exam questions about them.

Notice that safe(false) prints "release 3" before "caught". That ordering is the whole guarantee: the resource is freed during stack unwinding, before control reaches the handler. No amount of careful delete placement in leak_throw could achieve that, because the delete line is simply never reached.

Allocation failure and the this-pointer trap

failure.cpp

#include <iostream>
#include <new>

int main() {
    /* new THROWS on failure, it does not return null */
    try {
        long long huge = 1LL << 50;      /* ~1 PB */
        double *p = new double[huge];
        std::cout << "somehow succeeded\n";
        delete[] p;
    } catch (const std::bad_alloc &e) {
        std::cout << "bad_alloc: " << e.what() << "\n";
    }

    /* the nothrow form returns nullptr instead */
    double *q = new (std::nothrow) double[1LL << 50];
    std::cout << "nothrow gave "
              << (q ? "a pointer" : "nullptr") << "\n";
    delete[] q;               /* deleting nullptr is safe */

    /* checking new's result for null is pointless in the
       normal form — it never returns null. Writing
         if (!p) ...
       after a plain new is dead code. */
    return 0;
}
Output:
bad_alloc: std::bad_alloc
nothrow gave nullptr

🌍 Go further: two directions from here, both practical. First, placement new lets you construct an object at an address you already own — it is how std::vector avoids constructing elements it has reserved but not used, and how memory pools in game engines work. Second, tools: run any program of yours under valgrind --leak-check=full or compile with -fsanitize=address and it will name the exact line of every leak and every double-free. Search "AddressSanitizer use after free" — these tools turn the abstract bugs on this page into a filename and line number, which changes how you debug forever.

💡 Exam angle: the new/delete versus malloc/free comparison table is asked nearly every year — the critical rows are that new calls the constructor and delete the destructor, and that new throws bad_alloc rather than returning NULL. Know that new[] must pair with delete[] and why (all destructors versus one). Be ready to compare stack and heap on lifetime, size, speed and who frees. Show a leak from an early return or exception and fix it with a destructor or unique_ptr.

Syllabus points

new / delete; object arrays

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.