new and delete

Storage, Object Lifetime and Ownership

Dynamic allocation has three distinct ideas that beginners often mix:

1. Storage: bytes must be obtained with suitable size and alignment.
2. Object lifetime: an object is initialized/constructed in that storage and later destroyed.
3. Ownership: some program component is responsible for ending the lifetime and releasing the resource exactly once.

A C++ new-expression normally combines allocation and initialization, then yields a pointer. A delete-expression destroys the pointed-to object and invokes the corresponding deallocation function.

int local = 42;              // automatic lifetime: preferred when possible
int* dynamic = new int{42}; // dynamic lifetime: manual ownership
delete dynamic;
dynamic = nullptr;

Single-Object new and delete

#include <iostream>

int main() {
    int* score = new int{95};
    std::cout << "Score: " << *score << '\n';

    delete score;
    score = nullptr;
}

new int{95} allocates and initializes one integer. The returned pointer is dereferenced with *score. Exactly one matching delete score is required along every successful ownership path.

After deletion, the old pointer value is dangling and must not be read or dereferenced. Assigning nullptr helps this variable, but any copied pointer still dangles. That is why “remember to delete” is not a scalable ownership strategy.

Brace initialization makes the intended initial value explicit and rejects many narrowing conversions.

Dynamic Arrays and Matching Forms

int* marks = new int[3]{72, 88, 91};
for (int i = 0; i < 3; ++i) {
    std::cout << marks[i] << ' ';
}
delete[] marks;
marks = nullptr;

The syntax pair is strict:

Mixing the forms, deleting the same allocation twice, deleting an interior pointer, or deleting storage not obtained by a matching new-expression causes undefined behavior.

Prefer a container:

std::vector<int> marks{72, 88, 91};
marks.push_back(96); // owns memory, tracks size, releases automatically

Vector supplies size, bounds-aware at(), iteration and exception-safe cleanup. Use std::string for text rather than manually managed character arrays. Continue with vector and dynamic-memory fundamentals.

Object Construction and Destruction

#include <iostream>
#include <string>
#include <utility>

class Student {
public:
    explicit Student(std::string name) : name_(std::move(name)) {
        std::cout << "Constructed: " << name_ << '\n';
    }
    ~Student() {
        std::cout << "Destroyed: " << name_ << '\n';
    }
    void print() const { std::cout << "Student: " << name_ << '\n'; }
private:
    std::string name_;
};

int main() {
    Student* student = new Student{"Aman"};
    student->print();
    delete student;
}

Construction completes before new returns. delete first invokes the destructor and then deallocates storage. For arrays of class objects, delete[] destroys each constructed element.

If a constructor throws, the new-expression releases the storage it obtained through the matching deallocation mechanism; no pointer is returned. Resources acquired inside class members should themselves be RAII owners so partial construction is safely unwound. See destructors.

Allocation Failure and Advanced Forms

Throwing new

#include <cstddef>
#include <new>

constexpr std::size_t huge_count = 1'000'000;

try {
    auto* data = new int[huge_count];
    delete[] data;
} catch (const std::bad_alloc&) {
    // recover, report, or propagate at an appropriate boundary
}

Ordinary allocation failure normally throws std::bad_alloc. Catch it only where the program has a meaningful recovery policy; blindly retrying can worsen memory pressure.

Nothrow new

int* value = new (std::nothrow) int{7};
if (value == nullptr) {
    // handle failure
} else {
    delete value;
}

The nothrow form returns null on allocation failure. It does not remove other exceptions that an object's constructor may throw.

Placement new: advanced infrastructure tool

alignas(Student) std::byte storage[sizeof(Student)];
Student* p = new (storage) Student{"Aman"};
p->~Student(); // storage itself was not allocated by ordinary new

Placement new constructs an object in supplied storage. Do not apply ordinary delete to that pointer. Correct alignment, lifetime reuse, exceptions and explicit destruction make this a low-level technique for allocators/containers, not ordinary application code.

Ownership Rules and Failure Modes

void process(const Student* student);       // non-owning observation
void take(std::unique_ptr<Student> student); // ownership transfer
Student& require_student(Student& student);  // non-null borrowed object

A raw pointer or reference should normally be a non-owning view. If an API transfers ownership, express that in a smart-pointer type and document nullability/lifetime. Never create two independent owning smart pointers from the same raw pointer.

RAII, unique_ptr and shared_ptr

Resource Acquisition Is Initialization (RAII) ties resource ownership to an object's lifetime. Cleanup happens in the destructor on normal return, early return and exception unwinding.

#include <memory>

int main() {
    auto student = std::make_unique<Student>("Aman");
    student->print();
} // Student is destroyed automatically

Prefer unique_ptr: its ownership is explicit, movable and inexpensive. Use shared_ptr only when the ownership graph genuinely requires reference-counted shared lifetime; cycles need weak_ptr or a redesigned owner relationship.

Do not pass shared_ptr everywhere by habit. Pass T&/const T& when a function only uses an existing object, and pass/return an owning type only when ownership semantics require it. Study smart pointers.

Common Mistakes and 100-Point Safety Checklist

1. Can the object have automatic storage?
2. Can a standard container own the data?
3. Is the owner visible in the type?
4. Is exclusive ownership sufficient?
5. Are allocation/deallocation forms matched?
6. Are exceptions and early returns safe?
7. Are all borrows shorter than the owner lifetime?
8. Are array bounds and sizes explicit?
9. Are AddressSanitizer/UndefinedBehaviorSanitizer tests run?
10. Does review find zero naked owning new/delete outside RAII internals?

g++ -std=c++20 -Wall -Wextra -Wpedantic \
    -fsanitize=address,undefined -fno-omit-frame-pointer app.cpp

Authoritative References

• C++ Working Draft: New Expressions
• C++ Working Draft: Delete Expressions
• C++ Core Guidelines: Avoid explicit new and delete

The object-lifetime, matching-form and allocation-failure rules were checked against the current working draft. The production guidance follows the C++ Core Guidelines: prefer scoped objects, RAII containers and ownership types over naked owning new/delete.