C++ Virtual Destructor Pitfalls — Polymorphic Leaks

Every program manages resources — memory, file handles, network connections, database locks. In C, you had to manually open every resource and manually close it; if anything went wrong in between, you were left with leaks that could crash servers and corrupt data. C++ was designed from the ground up to fix this. Constructors and destructors are the foundation of that fix. They're not just syntax sugar — they're the mechanism that makes C++ the language of choice for systems where resource safety is non-negotiable, from game engines to operating systems to financial trading platforms.

The core problem they solve is predictability. Without a guaranteed setup and teardown mechanism, object state is fragile — you rely on the programmer to remember to call init() before using an object and cleanup() afterward. Constructors guarantee that an object is fully initialised the instant it exists. Destructors guarantee that cleanup happens the instant an object goes out of scope, no matter how the scope exits — whether normally, or via an exception.

By the end of this article, you'll understand not just how to write constructors and destructors, but why each type exists, how the RAII pattern makes resource management automatic, and the exact mistakes that cause memory leaks and double-free crashes in production codebases.

What Constructors Actually Do (and Why You Can't Skip Them)

A constructor is a special member function that runs automatically the moment an object is created. It has the same name as the class and no return type — not even void. This 'no return type' rule isn't arbitrary: the language designers wanted it to be unmistakably distinct from regular functions because it behaves differently. It doesn't return a value to a caller; it initialises the object in place.

The most important thing to understand is that C++ guarantees the constructor runs before any code can use the object. This makes it impossible to accidentally use an uninitialised object. If construction fails (for example, a new allocation inside the constructor throws), the object never exists in the first place, ensuring you never have to deal with 'zombie' objects in half-broken states.

C++ provides several constructor types: the default constructor (no arguments), parameterised constructors (custom state), the copy constructor (cloning), and the move constructor (ownership transfer). Reaching for the right one is a matter of performance—especially when objects hold expensive resources like heap memory or socket handles.

/* 
 * Copyright (c) 2026 TheCodeForge.io
 * Package: io.thecodeforge.finance
 */
#include <iostream>
#include <string>

namespace io_thecodeforge {
    class BankAccount {
    private:
        std::string ownerName;
        double balance;
        int accountNumber;

    public:
        // DEFAULT CONSTRUCTOR - Uses Delegation to minimize code duplication
        BankAccount() : BankAccount("Unknown", 0.0, 0) {
            std::cout << "[Default] Delegated to parameterized constructor.\n";
        }

        // PARAMETERISED CONSTRUCTOR - Uses Member Initializer List (Efficient)
        BankAccount(const std::string& name, double initialDeposit, int accNum)
            : ownerName(name), balance(initialDeposit), accountNumber(accNum) {
            std::cout << "[Parameterized] Created account: " << accountNumber << "\n";
        }

        void printDetails() const {
            std::cout << "Owner: " << ownerName << " | Balance: $" << balance << "\n";
        }
    };
}

int main() {
    using namespace io_thecodeforge;
    BankAccount aliceAccount("Alice Johnson", 5000.00, 10042);
    aliceAccount.printDetails();
    return 0;
}

Constructor vs Destructor — Side-by-Side Comparison

Understanding the precise differences between constructors and destructors is crucial for writing correct C++ code. While constructors handle setup, destructors handle teardown. The following table summarizes the key differences:

Use this table as a quick reference. Remember that constructors can be overloaded, but destructors cannot. Also note that destructors should never throw, while constructors can throw to indicate failure. These two functions are the bookends of an object's lifetime; knowing their differences helps avoid subtle bugs in polymorphic hierarchies.

The `explicit` Keyword — Preventing Silent Implicit Conversions

Single-argument constructors in C++ are implicit conversion points by default. This means the compiler can use them to convert a value of the parameter type to an object of the class type automatically, without any cast. While this is convenient for something like std::string (const char* to std::string), it can lead to subtle bugs when you don't expect the conversion.

For example, a class Account with a constructor Account(int balance) would allow a function void process(const Account&) to be called as process(1000). The integer 1000 is silently converted to an Account. This hides the fact that an object is being created, and can lead to unintended copies or unexpected resource consumption.

The explicit keyword (C++98) disables this implicit conversion. When a constructor is declared explicit, the programmer must use brace or parenthesis syntax explicitly: Account a{1000}. This makes the creation of the object visible in code reviews and prevents accidental conversions.

In modern C++ (C++20), you can use explicit(bool) to conditionally enable implicit conversion based on a template parameter. This is powerful for generic code where you want implicit conversion for some types but not others.

Best practice: Mark every single-argument constructor explicit unless you have a specific reason to allow implicit conversion. For multi-argument constructors, explicit is not relevant because they cannot participate in implicit conversions.

#include <iostream>

class Account {
public:
    // Without explicit, this allows implicit conversion from int
    /*explicit*/ Account(int balance) : balance_(balance) {
        std::cout << "Account created with balance " << balance_ << "\n";
    }
private:
    int balance_;
};

void deposit(const Account& acc) {
    std::cout << "Depositing into account\n";
}

int main() {
    // If constructor is not explicit, this compiles:
    deposit(1000);   // Implicitly creates Account(1000)

    // With explicit, this line would cause a compile error:
    // deposit(1000); // Error: no implicit conversion
    // Programmer must write:
    deposit(Account{1000}); // Explicit construction
    return 0;
}

Destructors and RAII — The Pattern That Makes C++ Resource-Safe

A destructor is the mirror of a constructor. It runs automatically when an object's lifetime ends — when it goes out of scope on the stack, or when delete is called on a heap-allocated object. It has the same name as the class, prefixed with a tilde (~), takes no parameters, and returns nothing. You can only have one per class.

The reason destructors matter so deeply is a design pattern called RAII — Resource Acquisition Is Initialisation. The idea: tie the lifetime of a resource directly to the lifetime of an object. Acquire the resource in the constructor, release it in the destructor. Because the destructor is guaranteed to run when the object goes out of scope — including when an exception unwinds the stack — you get automatic, exception-safe cleanup for free.

This is how std::fstream, std::unique_ptr, and std::lock_guard work. You don't call file.close() manually because the destructor handles it. This eliminates an entire class of bugs. If your class acquires a resource (heap memory, a file, a mutex, a socket), you need a destructor.

/* 
 * Copyright (c) 2026 TheCodeForge.io
 * Package: io.thecodeforge.logging
 */
#include <iostream>
#include <fstream>
#include <string>
#include <stdexcept>

namespace io_thecodeforge {
    class FileLogger {
    private:
        std::ofstream logFile;
        std::string   filePath;

    public:
        explicit FileLogger(const std::string& path) : filePath(path) {
            logFile.open(filePath, std::ios::app);
            if (!logFile.is_open()) {
                throw std::runtime_error("Failed to open log: " + filePath);
            }
            std::cout << "[RAII] File resource acquired.\n";
        }

        // Destructor: The 'Teardown' phase
        ~FileLogger() {
            if (logFile.is_open()) {
                logFile.close();
                std::cout << "[RAII] File resource released automatically.\n";
            }
        }

        void log(const std::string& message) {
            logFile << message << "\n";
        }

        // Prevent accidental copying (would cause double-close issues)
        FileLogger(const FileLogger&) = delete;
        FileLogger& operator=(const FileLogger&) = delete;
    };
}

int main() {
    { 
        io_thecodeforge::FileLogger logger("session.log");
        logger.log("System check OK.");
    } // Destructor fires here as logger goes out of scope
    return 0;
}

Private Destructors — Controlling Object Lifetime from Within

A destructor can be declared private in C++. This prevents code outside the class (including stack allocation) from destroying objects directly. The only way to destroy such objects is through a friend function or a member function (often a static factory method).

Important: Even with a private destructor, you can still create objects dynamically (via new), but you cannot delete them from outside the class. You must provide a static member function or friend that calls delete or delete[].

Another nuance: If a class has a private destructor and you try to create an automatic (stack) object, the compiler will reject it because the implicit destruction on scope exit is unavailable. Similarly, if you inherit from such a class, the derived class destructor will be unable to call the base destructor, so the base class must be declared final or the derived class must be a friend or use a workaround.

#include <iostream>
#include <memory>

class HeapOnly {
private:
    ~HeapOnly() {
        std::cout << "Private destructor called\n";
    }
public:
    HeapOnly() {
        std::cout << "HeapOnly created\n";
    }

    // Public static method to destroy the object
    static void destroy(HeapOnly* p) {
        delete p;  // OK: member function can access private destructor
    }

    // Factory method returning unique_ptr with custom deleter
    static std::unique_ptr<HeapOnly, void(*)(HeapOnly*)> create() {
        return { new HeapOnly(), &HeapOnly::destroy };
    }
};

int main() {
    // HeapOnly obj; // Error: destructor is private

    auto p = HeapOnly::create();  // OK: dynamic allocation, custom deleter
    // When p goes out of scope, custom deleter calls destroy
    return 0;
}

Virtual Destructors: The Silent Resource Leak in Class Hierarchies

When you delete a derived class object through a base class pointer, C++ must call the correct destructor for the complete object. If the base destructor is not virtual, the call is resolved statically — only the base destructor runs. The derived destructor is never called. This is the 'static type vs dynamic type' problem.

The fix is simple: declare the base class destructor as virtual. Once virtual, the destructor call uses the vtable to dispatch to the most derived destructor, which then calls the base destructor automatically in reverse order of construction.

A common misconception is that you only need a virtual destructor if the class has virtual functions. That's wrong. If you ever intend to delete a derived object through a base pointer, regardless of other virtual functions, the base destructor must be virtual. The cost is one vtable pointer per object (usually 8 bytes) — negligible compared to a memory leak in production.

/* 
 * Copyright (c) 2026 TheCodeForge.io
 * Package: io.thecodeforge.network
 */
#include <iostream>
#include <memory>

namespace io_thecodeforge {
    class Connection {
    public:
        Connection() { std::cout << "Connection ctor\n"; }
        virtual ~Connection() { std::cout << "Connection virtual dtor\n"; }
        virtual void send(const std::string&) = 0;
    };

    class TcpConnection : public Connection {
        int socketFd;
    public:
        TcpConnection() : socketFd(42) { std::cout << "TcpConnection ctor\n"; }
        ~TcpConnection() override {
            std::cout << "TcpConnection dtor: closing socket " << socketFd << "\n";
            // close(socketFd);
        }
        void send(const std::string& msg) override { /* send */ }
    };
}

int main() {
    using namespace io_thecodeforge;
    std::unique_ptr<Connection> conn = std::make_unique<TcpConnection>();
    conn->send("hello");
    // unique_ptr destructor calls delete via base pointer — virtual ensures full cleanup
    return 0;
}

Pure Virtual Destructors — Making Abstract Classes Safe to Delete

A pure virtual destructor is a destructor declared with = 0 in a base class. This makes the class abstract (cannot be instantiated), but unlike other pure virtual functions, a pure virtual destructor must still have a definition. Why? Because the derived class destructor will call the base destructor during destruction — if the base destructor is pure virtual but undefined, the linker will fail with an unresolved external symbol.

The typical pattern is to declare the destructor as pure virtual and then provide an empty implementation out-of-line:

```cpp class AbstractBase { public: virtual ~AbstractBase() = 0; // pure virtual };

// Must provide implementation: AbstractBase::~AbstractBase() {} ```

When would you use a pure virtual destructor? When you want a class to be abstract (uninstantiable) but you don't have any other pure virtual functions to declare. A common example is a base interface class that only has non-virtual utility functions or data members. By making the destructor pure virtual, you force derived classes to be complete, but you still get the guarantee that destructor chaining works correctly.

Important: The derived class destructor is still responsible for its own cleanup, and it will call the base destructor (the implementation you provided) after its own body. This allows the abstract base to have its own resource management if needed.

#include <iostream>

// Abstract class with pure virtual destructor
class Shape {
public:
    Shape() { std::cout << "Shape ctor\n"; }
    virtual ~Shape() = 0;  // Makes Shape abstract
    virtual double area() const = 0;
};

// Must define the pure virtual destructor
Shape::~Shape() {
    std::cout << "Shape dtor (base cleanup)\n";
}

class Circle : public Shape {
    double radius;
public:
    Circle(double r) : radius(r) {
        std::cout << "Circle ctor\n";
    }
    ~Circle() override {
        std::cout << "Circle dtor\n";
    }
    double area() const override {
        return 3.14159 * radius * radius;
    }
};

int main() {
    // Shape s; // Error: abstract class
    Shape* s = new Circle(5.0);
    std::cout << "Area: " << s->area() << "\n";
    delete s;  // Calls ~Circle() then ~Shape()
    return 0;
}

Copy, Move, and the Rule of Five — When the Compiler Gets It Wrong

If your class manages a raw resource (a raw pointer, a file descriptor), the compiler-generated copy constructor will do a shallow copy. Now two objects think they own the same memory. When both destructors run, you get a double-free crash. This is one of the most common sources of undefined behaviour in C++.

The Rule of Five states: if you define any one of — destructor, copy constructor, copy assignment, move constructor, or move assignment — you almost certainly need to define all five. They are a package deal because they all relate to resource ownership semantics.

The move constructor and move assignment operator (C++11) are the performance piece. Instead of deep-copying an expensive resource from a temporary object, you 'steal' the resource and leave the temporary in a null state. It's the difference between duplicating a 1GB file and simply renaming it.

/* 
 * Copyright (c) 2026 TheCodeForge.io
 * Package: io.thecodeforge.memory
 */
#include <iostream>
#include <cstring>
#include <utility>

namespace io_thecodeforge {
    class ManagedBuffer {
    private:
        char* data;
        size_t size;

    public:
        explicit ManagedBuffer(size_t bufferSize)
            : size(bufferSize), data(new char[bufferSize]()) {}

        ~ManagedBuffer() {
            delete[] data;
        }

        // Rule of 5: Deep Copy Constructor
        ManagedBuffer(const ManagedBuffer& other) : size(other.size) {
            data = new char[size];
            std::memcpy(data, other.data, size);
        }

        // Rule of 5: Move Constructor (Efficient Ownership Transfer)
        ManagedBuffer(ManagedBuffer&& other) noexcept 
            : data(other.data), size(other.size) {
            other.data = nullptr;
            other.size = 0;
        }

        ManagedBuffer& operator=(const ManagedBuffer&) = default;
        ManagedBuffer& operator=(ManagedBuffer&&) = default;
    };
}

int main() {
    io_thecodeforge::ManagedBuffer buf1(1024);
    io_thecodeforge::ManagedBuffer buf2 = std::move(buf1); // Move constructor used
    return 0;
}

The Rule of Zero — When You Shouldn't Write Any Special Functions

The Rule of Zero, popularized by Scott Meyers, states that classes should avoid defining any of the special member functions (destructor, copy/move constructor/assignment) if they don't manage resources directly. Instead, use resource-management classes like std::unique_ptr, std::shared_ptr, std::string, std::vector, etc. The compiler-generated special functions will then be correct and efficient. This is the ideal: let the types that own resources handle the bookkeeping, and your class stays simple.

Contrast this with the Rule of Five. The Rule of Five exists because sometimes you must manage a novel resource (e.g., a file descriptor, a custom memory pool). But in modern C++, you can almost always wrap that resource inside a library class. For example, instead of a raw FILE, use std::fstream. Instead of a raw char, use std::string. Instead of a raw allocation of int*, use std::vector<int>.

When you use these library types, the compiler-generated destructor, copy constructor, move constructor, copy assignment, and move assignment are all automatically correct. They will call the respective operations of each member, which in turn manage their own resources. You get exception safety, deep copy when needed, and move semantics when possible — all for free.

The Rule of Zero is not just about convenience; it dramatically reduces the surface for bugs. In production codebases, most memory leaks and double-frees occur in classes that manually manage resources. By following the Rule of Zero, you eliminate those bugs entirely.

In modern C++, aim for Rule of Zero as your default. Write a custom special member function only when you have a class that manages a resource not already wrapped by the standard library. And when you do, write all five (or delete the ones you don't want).

#include <iostream>
#include <memory>
#include <string>
#include <vector>

// BAD: Rule of Five needed for raw pointer
class BadStringOwner {
    char* data;
public:
    BadStringOwner(const char* s) {
        data = new char[strlen(s)+1];
        strcpy(data, s);
    }
    ~BadStringOwner() { delete[] data; }
    // Need copy/move/assignment (omitted for brevity)
};

// GOOD: Rule of Zero — no special functions needed
class GoodStringOwner {
    std::string data;
public:
    GoodStringOwner(const std::string& s) : data(s) {}
    // Compiler-generated dtor, copy, move are all correct
};

// BAD: Rule of Five needed for raw pointer
class BadBuffer {
    int* arr;
    size_t size;
public:
    BadBuffer(size_t n) : size(n), arr(new int[n]) {}
    ~BadBuffer() { delete[] arr; }
    // Need copy/move/assignment
};

// GOOD: Rule of Zero — use vector
class GoodBuffer {
    std::vector<int> arr;
public:
    GoodBuffer(size_t n) : arr(n) {}
    // All automatic
};

int main() {
    GoodStringOwner gso("hello");
    GoodBuffer gb(100);
    // Both are safely copyable and movable without manual code
    return 0;
}

Constructor Delegation and Member Initializer Lists — Production Patterns

Constructor delegation (C++11) lets one constructor call another constructor of the same class. This reduces duplication of initialisation logic. The delegate call must appear in the member initializer list, not in the body. If you put it in the body, you're not delegating — you're constructing a temporary.

Member initializer lists are the preferred way to initialise member variables because they construct members directly. Without them, members are default-constructed and then assigned, which is wasteful for types like std::string, std::vector, or any user-defined type with non-trivial constructors. For const and reference members, the initializer list is mandatory because they cannot be assigned after default construction.

In production, use delegation when you have multiple constructors that all share a common setup — like initializing a logger, establishing a database connection, or validating invariants. The delegating constructor runs after the delegated constructor completes, so any code in its body can assume the object is fully set up.

/* 
 * Copyright (c) 2026 TheCodeForge.io
 * Package: io.thecodeforge.database
 */
#include <iostream>
#include <string>

namespace io_thecodeforge {
    class DatabaseConnection {
    private:
        std::string host;
        int port;
        bool connected;

    public:
        // Primary constructor with all parameters
        DatabaseConnection(const std::string& h, int p) 
            : host(h), port(p), connected(false) {
            std::cout << "Connecting to " << host << ":" << port << "\n";
            connected = true;
        }

        // Delegating: creates a connection with default port (5432)
        explicit DatabaseConnection(const std::string& h) 
            : DatabaseConnection(h, 5432) {
            std::cout << "Delegated from single-arg constructor.\n";
        }

        // Default constructor: delegates to the single-arg constructor with "localhost"
        DatabaseConnection() : DatabaseConnection("localhost") {
            std::cout << "Default constructor complete.\n";
        }

        bool isConnected() const { return connected; }
    };
}

int main() {
    io_thecodeforge::DatabaseConnection d1("prod-server", 3306);
    io_thecodeforge::DatabaseConnection d2("dev-server");
    io_thecodeforge::DatabaseConnection d3; // localhost:5432
    return 0;
}

Putting It All Together: RAII in Action with Dockerized Testing

To validate that your resource management patterns are robust, deploy a stress test inside a Docker container. This isolates the test from your host environment and allows monitoring tools to catch memory leaks early. The following Dockerfile builds a performance test that creates and destroys thousands of RAII objects, checking for resource exhaustion.

A common trap: even with perfect RAII, if you use std::make_unique in a constructor body instead of the initializer list, you risk a memory leak if the constructor throws after allocation. Always use the initializer list for members. The container build also demonstrates multi-stage builds — keeping the final image small while maintaining reproducibility.

# Package: io.thecodeforge.infrastructure
# Multi-stage build for production-grade binary
FROM gcc:13 AS build

WORKDIR /app
COPY . .
RUN g++ -O3 -std=c++20 -fsanitize=address -g main.cpp -o performance_test

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y libstdc++6 && rm -rf /var/lib/apt/lists/*
COPY --from=build /app/performance_test /usr/local/bin/
CMD ["performance_test"]

Practice Exercises — Apply Constructor/Destructor Patterns

Test your understanding with these real-world inspired exercises. Each reinforces one key concept from this article. Attempt them before looking at the hints or solutions.

1. RAII File Manager Write a class FileManager that opens a file in its constructor (using std::fstream) and closes it in the destructor. Ensure that the class cannot be copied (delete copy operations). In main(), demonstrate that the file is properly closed when the object goes out of scope. Use std::ofstream::is_open() to verify. Concept: RAII, implicit destructor call, copy prevention.

2. Smart Pointer Clone Design a base class Clonable with a virtual destructor and a pure virtual clone() method returning std::unique_ptr<Clonable>. Implement two derived classes. Show that you can copy polymorphic objects by calling clone() through a base pointer, and that deleting the original does not affect the clone. Concept: virtual destructor, virtual clone idiom for polymorphic copying.

3. Virtual Destructor Hierarchy Create a base class Transport with a non-virtual destructor. Derive Car and Boat. In main(), delete a Boat object through a Transport* and observe that the derived destructor is not called (add print statements). Then make the base destructor virtual and see the correct behaviour. Concept: static vs dynamic type, virtual destructor necessity.

4. Private Destructor Singleton Implement a singleton class Logger with a private destructor. Provide a static instance() method that returns a reference to the single instance. Ensure that the singleton cannot be destroyed from outside. (Note: In production, use a static local variable or std::shared_ptr — this exercise focuses on destructor access control.) Concept: private destructor, static factory, lifetime control.

5. Rule of Zero Refactor Given a class LegacyBuffer that manages a raw char* and has a destructor, copy constructor, etc., refactor it to use std::string and/or std::unique_ptr, eliminating all custom special member functions. Show that the new class is correct and simpler. Concept: Rule of Zero, resource ownership transfer, eliminating boilerplate.

#include <iostream>
#include <fstream>
#include <string>

class FileManager {
private:
    std::ofstream file_;
public:
    explicit FileManager(const std::string& path) {
        file_.open(path);
        if (!file_.is_open()) {
            throw std::runtime_error("Failed to open file");
        }
        std::cout << "File opened\n";
    }

    ~FileManager() {
        if (file_.is_open()) {
            file_.close();
            std::cout << "File closed in destructor\n";
        }
    }

    // Prevent copying (would cause double close)
    FileManager(const FileManager&) = delete;
    FileManager& operator=(const FileManager&) = delete;

    void write(const std::string& line) {
        file_ << line << std::endl;
    }
};

int main() {
    {
        FileManager fm("test.txt");
        fm.write("Hello, RAII");
    }   // Destructor closes file automatically
    return 0;
}

When Is the Destructor Called? — Not When You Think

Every C++ dev knows destructors fire on scope exit. The part they forget: order of destruction is reverse order of construction — including base classes and member objects. That's not a trivia fact; it's the difference between a clean shutdown and a segfault.

Local variables unwind in reverse declaration order. Class members are destroyed in reverse of their declaration order (not initialization order, declaration order). Base class destructors run after derived destructors complete. If you allocate a resource in a member declared second but use it in a member declared first, you've just written a use-after-free bug waiting to happen.

Dynamic objects are trickier. You can destroy them early with delete, but only if you own the pointer. For smart pointers, destruction happens when the last shared_ptr goes out of scope or the unique_ptr goes null — which can be anywhere in your codebase. That's why RAII works: destruction timing is deterministic and tied to the scope you control.

// io.thecodeforge — c-cpp tutorial

#include <iostream>

class Logger {
public:
    Logger(const char* name) : name(name) {
        std::cout << "Construct: " << name << "\n";
    }
    ~Logger() {
        std::cout << "Destruct:  " << name << "\n";
    }
private:
    const char* name;
};

class NetworkConnector {
    Logger log{"NetworkConnector"};
public:
    void transmit() { std::cout << "Sending data...\n"; }
    ~NetworkConnector() { std::cout << "Closing socket...\n"; }
};

class DatabaseHandler {
    NetworkConnector net;
    Logger log{"DatabaseHandler"};
public:
    void save() { net.transmit(); }
};

int main() {
    DatabaseHandler db;
    db.save();
    return 0;
}

Explicit Destructor Calls — When You Need Manual Cleanup

You almost never call a destructor manually. The compiler handles it. But placement new and memory pools break that rule. When you allocate raw memory and construct an object into it with placement new, the compiler doesn't know the object exists — so it won't call the destructor when the memory goes out of scope. You must call it explicitly.

The syntax is ugly on purpose: object.~ClassName(). That's a direct invocation, no pointer needed. For dynamic arrays in custom allocators, you iterate and call destructors on each element manually before deallocating the raw memory. Miss one, and you leak resources. Call it twice, and you get undefined behavior — usually a corrupt heap or crash.

Another case: objects stored in unions. C++11 and later allow non-trivial types in unions, but you're responsible for manually calling the destructor before changing the active member. The compiler won't do it for you. This is rare but deadly when it bites you in parsing or protocol code.

// io.thecodeforge — c-cpp tutorial

#include <iostream>
#include <new>

class SocketConnection {
    int fd;
public:
    SocketConnection(int port) : fd(port) {
        std::cout << "Socket opened on port " << port << "\n";
    }
    ~SocketConnection() {
        std::cout << "Closing socket " << fd << "\n";
    }
};

int main() {
    char buffer[sizeof(SocketConnection)];
    SocketConnection* sock = new (buffer) SocketConnection(8080);

    sock->~SocketConnection();  // explicit destructor call
    // buffer is now raw memory again — no automatic cleanup

    return 0;
}