C Memory Leak — 30 Bytes/Req Crashed at 12h

Every real-world C program — from embedded firmware in your car to the Linux kernel — has one thing in common: they can't always know at compile time how much memory they'll need. A web server doesn't know how many simultaneous connections it'll handle. A text editor doesn't know how long the document will be. If you hardcode array sizes, you either waste memory or crash when input exceeds your guess. This is the gap dynamic memory management was built to fill.

C gives you direct control over the heap — a large pool of memory your program can borrow from at runtime. The standard library functions malloc, calloc, realloc, and free are your tools for doing that. Unlike stack memory, which is automatically managed as functions are called and return, heap memory lives until YOU explicitly release it. That power is also the responsibility: C won't clean up after you.

By the end of this article you'll understand not just the syntax of these four functions, but WHY each one exists, when to choose one over another, how to detect and prevent memory leaks, and what interviewers are really testing when they ask about dynamic allocation. You'll have runnable code patterns you can drop straight into real projects.

Why Manual Memory Management in C Is a Double-Edged Sword

Memory management in C is the explicit allocation and deallocation of heap memory via malloc(), calloc(), realloc(), and free(). Unlike garbage-collected languages, C gives you full control — and full responsibility. Every malloc() returns a pointer to a block of memory; every successful allocation must eventually be matched with a free(). Fail to free, and you leak memory. Free too early, and you get a dangling pointer. Free twice, and you corrupt the heap. The core mechanic is simple: you own every byte you allocate, and the runtime will not clean up after you.

In practice, C's memory model is flat and contiguous. malloc() returns a void* to a block from the heap, typically managed by the OS via brk() or mmap(). The allocator tracks free chunks; fragmentation grows over time if you allocate and free irregularly. There is no bounds checking — writing past the end of an allocated buffer corrupts adjacent memory silently. This is why tools like Valgrind and AddressSanitizer exist: they catch what the language itself does not enforce.

Use manual memory management when you need predictable performance, minimal overhead, or are working on embedded systems, kernels, or real-time applications. It matters because a single leak in a long-running server can accumulate into a crash — as in the 30 bytes/request leak that brings down a service after 12 hours. Understanding C's memory model is not optional if you write systems software; it is the difference between a reliable daemon and a ticking time bomb.

Why the Stack Isn't Enough — The Case for Heap Allocation

When you declare int scores[100]; inside a function, it lives on the stack. The stack is fast, automatically managed, and perfect for small, fixed-size data. But it has two brutal limitations: its size is fixed (typically 1–8 MB), and every variable must have a known size at compile time.

Think about reading a CSV file with an unknown number of rows, or building a linked list that grows as users add items. You can't express that with stack arrays. You need memory you can size at runtime and control the lifetime of explicitly.

The heap is that place. It's a large region of memory (limited by your RAM and OS) that your program can request chunks from dynamically. The heap doesn't auto-clean — a chunk stays allocated until your code calls free on it. This is where malloc and its siblings come in: they're the formal interface between your program and the heap allocator.

One more thing: stack memory dies when the function returns. If you need data to outlive the function that created it — like returning a dynamically built string to a caller — the heap is the only option.

#include <stdio.h>
#include <stdlib.h>

// Demonstrates WHY stack allocation fails for runtime-sized data

// This function CANNOT work — you can't use a runtime value as a stack array size
// in C89/C90 (VLAs in C99 help but have their own problems — stack overflow risk)
void demonstrate_stack_limit(int user_count) {
    // VLA — risky for large counts, stack overflow if user_count is huge
    // int user_ids[user_count]; // C99 only, and dangerous for large values

    // The heap-based approach scales safely to millions:
    int *user_ids = malloc(user_count * sizeof(int));
    if (user_ids == NULL) {
        // Always check: malloc returns NULL if the OS can't satisfy the request
        fprintf(stderr, "Failed to allocate memory for %d users\n", user_count);
        return;
    }

    // Populate with demo data
    for (int i = 0; i < user_count; i++) {
        user_ids[i] = 1000 + i;  // Simulating real user IDs starting at 1000
    }

    printf("Allocated %d user IDs on the heap:\n", user_count);
    for (int i = 0; i < user_count; i++) {
        printf("  user_ids[%d] = %d\n", i, user_ids[i]);
    }

    free(user_ids);  // Return the memory — critical. Without this, it's a leak.
    user_ids = NULL; // Null the pointer so it can't be accidentally used after free
}

int main(void) {
    int count = 5;  // In a real app, this comes from user input or a config file
    demonstrate_stack_limit(count);
    return 0;
}

Stack vs Heap — Quick Comparison Table

When deciding where to place your data, it helps to see the key characteristics side by side. This table distills the most important differences between stack memory and heap memory in C.

When to use each: - Use the stack for small, fixed-size local variables, function parameters, and anything that doesn't need to outlive its function. It's fast, safe, and automatic. - Use the heap for large buffers, data structures that grow dynamically (linked lists, dynamic arrays, trees), and any data that must survive the function that created it.

The code below shows a concrete example of each allocation type and how to handle them correctly.

#include <stdio.h>
#include <stdlib.h>

// A simple function that uses both stack and heap

void demonstrate_both() {
    // Stack allocation: small, fixed size, automatic
    int local_array[5] = {10, 20, 30, 40, 50};
    printf("Stack array at %p: ", (void*)local_array);
    for(int i = 0; i < 5; i++) printf("%d ", local_array[i]);
    printf("\n");

    // Heap allocation: runtime size, explicit lifetime
    size_t count = 5;
    int *heap_array = malloc(count * sizeof(int));
    if (heap_array == NULL) {
        fprintf(stderr, "Heap allocation failed");
        return;
    }
    for(size_t i = 0; i < count; i++) {
        heap_array[i] = (int)(i * 100);
    }
    printf("Heap array at %p: ", (void*)heap_array);
    for(size_t i = 0; i < count; i++) printf("%d ", heap_array[i]);
    printf("\n");

    free(heap_array);
    heap_array = NULL;
}

int main() {
    demonstrate_both();
    return 0;
}

malloc vs calloc — Same Job, Different Guarantee

Both malloc and calloc allocate heap memory, but they differ in one critical way: calloc zeroes out the memory it allocates, while malloc leaves whatever garbage was there before.

malloc(n) takes a single argument — the number of bytes to allocate. It's the faster choice when you're about to overwrite every byte anyway (like reading from a file or socket into a buffer). The garbage contents don't matter because you'll replace them immediately.

calloc(count, size) takes two arguments — the number of elements and the size of each. It's designed specifically for arrays. Beyond the zero-initialization, it also handles the multiplication safely: if count * size would overflow a size_t, calloc can detect it. malloc with manual multiplication cannot.

Choose calloc when you need a guaranteed-zero starting state — like a boolean flags array, a counter array, or any structure where zero is a valid 'empty' sentinel. Choose malloc when you're going to initialize the memory yourself immediately, and you want the marginal performance gain of skipping the zero-fill.

Neither function initialises memory to any particular value beyond calloc's zero guarantee — use memset if you need a non-zero fill after malloc.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>  // for memset

// Struct representing a simple task in a to-do list
typedef struct {
    int  task_id;
    int  is_complete;   // 0 = pending, 1 = done
    int  priority;      // 1-5
} Task;

void demonstrate_malloc(void) {
    printf("--- malloc demo ---\n");

    // malloc: fast, but contents are UNDEFINED (garbage)
    Task *task = malloc(sizeof(Task));
    if (task == NULL) {
        fprintf(stderr, "malloc failed\n");
        return;
    }

    // We MUST initialise every field ourselves — there's no zero guarantee
    task->task_id    = 42;
    task->is_complete = 0;  // Explicitly set to pending
    task->priority   = 3;

    printf("Task %d: complete=%d, priority=%d\n",
           task->task_id, task->is_complete, task->priority);

    free(task);
    task = NULL;
}

void demonstrate_calloc(void) {
    printf("--- calloc demo ---\n");

    int task_count = 4;

    // calloc: allocates an array of 4 Task structs, ALL bytes zeroed
    // is_complete will be 0 (pending) for every task — no explicit init needed
    Task *task_list = calloc(task_count, sizeof(Task));
    if (task_list == NULL) {
        fprintf(stderr, "calloc failed\n");
        return;
    }

    // Only set the fields that differ from zero
    for (int i = 0; i < task_count; i++) {
        task_list[i].task_id  = 100 + i;
        task_list[i].priority = i + 1;   // priorities 1 through 4
        // is_complete is already 0 thanks to calloc — nothing to do
    }

    for (int i = 0; i < task_count; i++) {
        printf("Task %d: complete=%d, priority=%d\n",
               task_list[i].task_id,
               task_list[i].is_complete,
               task_list[i].priority);
    }

    free(task_list);
    task_list = NULL;
}

int main(void) {
    demonstrate_malloc();
    demonstrate_calloc();
    return 0;
}

Memory Function Signatures Reference Table

Every C programmer should have the exact prototypes of the four dynamic memory functions committed to muscle memory. Here they are, with their required header and a quick explanation of each argument.

Important details to remember: - All functions return void *, which means they can be assigned to any pointer type without an explicit cast in C (unlike C++). However, always assign to a pointer of the correct type after checking for NULL. - The size_t type is an unsigned integer defined in <stddef.h>. Guaranteeing that sizes fit in size_t is your responsibility — calloc's overflow check is a safety net, not a guarantee of success. - realloc(ptr, 0) is implementation-defined: it may free the block and return NULL, or it may return a unique pointer (C standard allows both). Avoid relying on this behaviour — use free(ptr) explicitly. - free(NULL) is safe and does nothing. This is why setting pointers to NULL after free is so effective: later calls to free become harmless.

The code below shows a complete example that uses all four signatures correctly, including error handling.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void) {
    // 1. malloc — allocate 10 integers, no initialisation
    int *arr = malloc(10 * sizeof(int));
    if (arr == NULL) {
        fprintf(stderr, "malloc failed\n");
        return 1;
    }

    // 2. calloc — allocate 10 integers, zero-initialised
    int *zero_arr = calloc(10, sizeof(int));
    if (zero_arr == NULL) {
        fprintf(stderr, "calloc failed\n");
        free(arr);
        return 1;
    }
    // zero_arr[0] is guaranteed 0

    // 3. realloc — grow arr to 20 integers, preserving first 10
    int *tmp = realloc(arr, 20 * sizeof(int));
    if (tmp == NULL) {
        // arr still valid; handle error
        fprintf(stderr, "realloc failed, original arr preserved\n");
        free(arr);
        free(zero_arr);
        return 1;
    }
    arr = tmp;  // safe assignment

    // 4. free — release both allocations
    free(arr);
    free(zero_arr);
    arr = NULL;
    zero_arr = NULL;

    return 0;
}

realloc and free — Growing Memory and Giving It Back

Once you've allocated memory, real programs often need to grow it. A dynamic array that starts at 10 elements might need 10,000 by the time the user is done. That's realloc's job: resize an existing allocation without you having to malloc a new block, memcpy the old data, and free the old pointer manually.

realloc takes your existing pointer and a new size. It tries to extend the block in place; if it can't, it allocates a new block, copies your data, and frees the old one automatically. The key danger: realloc returns a new pointer (which may differ from the old one), so you must assign the return value to a pointer variable. If you ignore it and keep using the old pointer, you're in undefined behaviour territory.

The classic growth pattern is to double capacity each time you run out — this gives amortised O(1) appends and is exactly how C++ std::vector works under the hood.

free is straightforward but has strict rules: only free pointers returned by malloc/calloc/realloc, never free the same pointer twice, and never use a pointer after freeing it. After calling free, immediately set the pointer to NULL — it costs nothing and prevents a whole class of bugs called use-after-free.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// A simple dynamic array of strings (like a growing log buffer)
typedef struct {
    char  **entries;       // Pointer to array of string pointers
    int     count;         // Current number of entries
    int     capacity;      // Total slots currently allocated
} LogBuffer;

// Initialise the log buffer with a small starting capacity
LogBuffer *log_buffer_create(void) {
    LogBuffer *log = malloc(sizeof(LogBuffer));
    if (log == NULL) return NULL;

    log->capacity = 4;   // Start small — we'll grow as needed
    log->count    = 0;
    log->entries  = malloc(log->capacity * sizeof(char *));
    if (log->entries == NULL) {
        free(log);
        return NULL;
    }
    return log;
}

// Append a message — grows the buffer if full
int log_buffer_append(LogBuffer *log, const char *message) {
    // Check if we need to grow
    if (log->count == log->capacity) {
        int new_capacity = log->capacity * 2;  // Double the capacity

        // CRITICAL: use a temp pointer — if realloc fails, we still have the original
        char **resized = realloc(log->entries, new_capacity * sizeof(char *));
        if (resized == NULL) {
            fprintf(stderr, "realloc failed — log buffer could not grow\n");
            return -1;  // Original log->entries is still valid here
        }

        log->entries  = resized;       // Now safe to update the pointer
        log->capacity = new_capacity;
        printf("[Buffer grew to capacity: %d]\n", new_capacity);
    }

    // Duplicate the string onto the heap so the caller's memory doesn't matter
    log->entries[log->count] = malloc(strlen(message) + 1);  // +1 for null terminator
    if (log->entries[log->count] == NULL) return -1;

    strcpy(log->entries[log->count], message);
    log->count++;
    return 0;
}

// Free everything — the strings, the array, then the struct itself
void log_buffer_destroy(LogBuffer *log) {
    for (int i = 0; i < log->count; i++) {
        free(log->entries[i]);   // Free each individual string first
        log->entries[i] = NULL;
    }
    free(log->entries);   // Free the array of pointers
    log->entries = NULL;
    free(log);            // Free the struct itself
    // Caller should set their LogBuffer* to NULL after this
}

int main(void) {
    LogBuffer *app_log = log_buffer_create();
    if (app_log == NULL) {
        fprintf(stderr, "Failed to create log buffer\n");
        return 1;
    }

    // Appending 6 entries will trigger one realloc (capacity 4 -> 8)
    log_buffer_append(app_log, "Server started on port 8080");
    log_buffer_append(app_log, "Database connection established");
    log_buffer_append(app_log, "Config file loaded");
    log_buffer_append(app_log, "Worker threads initialised");  // Triggers realloc here
    log_buffer_append(app_log, "First request received");
    log_buffer_append(app_log, "Health check passed");

    printf("\nLog entries (%d total):\n", app_log->count);
    for (int i = 0; i < app_log->count; i++) {
        printf("  [%d] %s\n", i + 1, app_log->entries[i]);
    }

    log_buffer_destroy(app_log);
    app_log = NULL;  // Prevent any accidental use after destroy
    return 0;
}

Detecting and Preventing Memory Leaks — Real Tools, Real Habits

A memory leak happens when you allocate heap memory and never free it. The program keeps running, keeps allocating, and eventually either runs out of memory or gets killed by the OS. In long-running processes — servers, daemons, embedded systems — even a tiny leak per request will eventually bring the system down.

The most effective tool for catching leaks is Valgrind (Linux/macOS). Run your program with valgrind --leak-check=full ./your_program and it'll report every byte that was allocated but not freed, including the exact line where the allocation happened. On Windows, use AddressSanitizer (built into MSVC and Clang with -fsanitize=address).

Beyond tools, the best defence is clean ownership patterns: every allocation should have a clear owner (the code responsible for freeing it), allocations and their matching frees should live in the same layer of abstraction (don't malloc in one module and free in another without a documented contract), and every pointer should be set to NULL after free.

The code below demonstrates a real leak, what Valgrind reports, and the fix.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Simulates loading configuration values — a common real-world pattern

// BAD VERSION — leaks the allocated string
char *load_config_value_leaky(const char *key) {
    // Pretend we read this from a file; we allocate a new string
    char *value = malloc(64);
    if (value == NULL) return NULL;
    snprintf(value, 64, "value_for_%s", key);  // Populate with demo data
    return value;  // Caller receives ownership — must free this
}

// GOOD VERSION — same function, but caller is reminded of ownership via comment
// Returns heap-allocated string. CALLER MUST FREE the returned pointer.
char *load_config_value(const char *key) {
    char *value = malloc(64);
    if (value == NULL) return NULL;
    snprintf(value, 64, "value_for_%s", key);
    return value;
}

void process_config_leaky(void) {
    // This leaks: we get a heap pointer but never free it
    char *db_host = load_config_value_leaky("db_host");
    printf("Leaky path — db_host: %s\n", db_host);
    // Forgot to call free(db_host) — 64 bytes leaked every call
}

void process_config_correct(void) {
    char *db_host = load_config_value("db_host");
    if (db_host == NULL) {
        fprintf(stderr, "Failed to load db_host config\n");
        return;
    }
    printf("Correct path — db_host: %s\n", db_host);

    free(db_host);   // We own it — we free it
    db_host = NULL;  // Nullify immediately
}

int main(void) {
    process_config_leaky();   // Run with Valgrind to see this reported
    process_config_correct(); // Valgrind will show zero leaks from this path

    // Valgrind command: valgrind --leak-check=full ./leak_detection
    // Leaky path output:
    //   LEAK SUMMARY: definitely lost: 64 bytes in 1 blocks
    //   at 0x...: malloc (in /usr/lib/valgrind/...)
    //   by 0x...: load_config_value_leaky (leak_detection.c:12)
    //   by 0x...: process_config_leaky (leak_detection.c:26)

    return 0;
}

Common Mistakes with Dynamic Memory and How to Debug Them

Even experienced C programmers make the same three mistakes: not checking malloc's return, double-freeing, and use-after-free. Each has a distinct symptom and a straightforward fix once you know what to look for.

Not checking malloc's return: If malloc returns NULL, dereferencing it is undefined behaviour — your program crashes with a segfault, but not consistently, because NULL may map to a valid address on some systems. Always check if (ptr == NULL) after every allocation.

Double-freeing: Calling free twice on the same pointer corrupts the heap's internal bookkeeping. The next malloc/calloc/realloc may crash, or data may be silently corrupted. The fix: set pointer to NULL after free, and guard with if (ptr) before calling free.

Use-after-free: Accessing memory after calling free on it. The memory may have been reallocated to another part of the program, so reading it gives garbage or writes corrupt other data. This is hard to reproduce. AddressSanitizer catches it deterministically.

Here's a code example showing all three mistakes and how to write them correctly.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    // Mistake 1: Not checking malloc's return
    int *data = malloc(100 * sizeof(int));
    // Should check: if (data == NULL) { ... }
    data[0] = 42; // If malloc failed, this dereferences NULL -> crash

    // Mistake 2: Double-free
    free(data);
    free(data); // Crash: double free or corruption

    // Mistake 3: Use-after-free
    // data was freed, but pointer still points to freed memory
    // printf("%d\n", data[0]); // Undefined behaviour

    // CORRECT PATTERN:
    int *safe_data = malloc(100 * sizeof(int));
    if (safe_data == NULL) {
        fprintf(stderr, "malloc failed\n");
        return 1;
    }
    safe_data[0] = 42;
    free(safe_data);
    safe_data = NULL; // Prevent double-free and use-after-free

    // Later accidental free(safe_data) is safe because free(NULL) is no-op
    free(safe_data); // Harmless

    return 0;
}

The Cost of Allocation — Why Every malloc Is a System Call Gamble

Memory allocation in C isn't free. Every call to malloc or calloc is a system call that requests memory from the kernel. That call costs CPU cycles, context switches, and cache misses. In hot code paths—like game loops, network request handlers, or real-time audio buffers—a single malloc can tank your latency budget.

For example, a classic production pipeline for a video game spawns enemy objects each frame. Calling malloc per enemy is a rookie mistake. The kernel has to service the request via mmap or sbrk, which may zero memory or acquire a mutex in the heap's free list. That's microseconds you don't have per frame. Java and Python hide this with garbage collection pauses; C gives you the control to avoid it entirely.

Why does this matter? Because the alternative is memory pools—pre-allocate a slab of memory once and carve it into fixed-size chunks. That turns allocation into a simple pointer increment. No syscall, no lock, no surprise. You want speed and determinism? That's how you get it.

// io.thecodeforge — c-cpp tutorial

#include <stdlib.h>
#include <stdio.h>

#define POOL_SIZE 1000
#define BLOCK_SIZE 64

static char memory_pool[POOL_SIZE * BLOCK_SIZE];
static int next_free = 0;

void* pool_alloc() {
    if (next_free >= POOL_SIZE) {
        fprintf(stderr, "Pool exhausted!\n");
        return NULL;
    }
    return &memory_pool[next_free++ * BLOCK_SIZE];
}

void pool_free_all() {
    next_free = 0;  // Reset, not free()
}

int main() {
    void* p1 = pool_alloc();
    void* p2 = pool_alloc();
    printf("Pool blocks: %p, %p\n", p1, p2);
    pool_free_all();
    return 0;
}

Alignment — The Hidden Landmine That Corrupts Your Data

Every type has an alignment requirement. An int wants a 4-byte boundary; a double wants an 8-byte boundary; a 16-byte SSE vector wants 16. When you allocate with malloc, it guarantees the pointer is aligned for the largest scalar type on your platform (usually 8 or 16 bytes). But custom allocators often skip this guarantee.

How does this bite you? Say you implement a slab allocator that returns offsets from a char array. On x86, unaligned access might work but cost 2x to 3x the CPU cycles. On ARM, it triggers a trap and your program crashes. Now your production server reboots every hour. Congrats, you've just learned why posix_memalign exists.

Real-world fix: align your pools to at least 16 bytes. Use alignas(16) in C++ or __attribute__((aligned(16))) in C. Check the pointer value after every custom alloc: if ((uintptr_t)ptr % 16 != 0) abort();. That abort will surface in your crash logs faster than silent data corruption.

// io.thecodeforge — c-cpp tutorial

#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>

void* aligned_malloc(size_t size, size_t alignment) {
    void* raw = malloc(size + alignment + sizeof(void*));
    if (!raw) return NULL;
    uintptr_t aligned = ((uintptr_t)raw + alignment + sizeof(void*)) & ~(alignment - 1);
    ((void**)aligned)[-1] = raw;  // store offset for free
    return (void*)aligned;
}

void aligned_free(void* ptr) {
    free(((void**)ptr)[-1]);
}

int main() {
    void* buf = aligned_malloc(1024, 16);
    printf("Aligned buffer: %p (mod 16 = %lu)\n", buf, (uintptr_t)buf % 16);
    aligned_free(buf);
    return 0;
}

Stop Using malloc/free in C++ — Here's Why

You're writing C++. Stop pretending it's C with classes. malloc and free have no business in modern C++ code. They don't call constructors or destructors. That means your objects start life uninitialized and die without cleanup. Leaked resources, dangling pointers, undefined behavior — the whole mess.

malloc returns void* that you manually cast. One wrong cast and you're corrupting memory. free doesn't run destructors — your std::vector never releases its heap buffer, your mutex stays locked. Production systems crash on this daily.

Use new/delete for single objects, new[]/delete[] for arrays. Better yet, skip all of it. std::make_unique and std::make_shared allocate and construct in one shot. No casts, no leaks, no forgotten destructors. The compiler enforces correctness. Your future self — and your on-call rotation — will thank you.

// io.thecodeforge — c-cpp tutorial

#include <iostream>
#include <string>

struct Config {
    std::string name;
    int timeout;
    Config() : name("default"), timeout(30) {
        std::cout << "Config constructed\n";
    }
    ~Config() { std::cout << "Config destroyed\n"; }
};

int main() {
    // malloc — constructor never called
    Config* cfg1 = (Config*)malloc(sizeof(Config));
    std::cout << cfg1->name << "\n";  // UB: garbage string

    // new — constructor called
    Config* cfg2 = new Config();
    std::cout << cfg2->name << "\n";  // "default"

    delete cfg2;   // destructor runs
    free(cfg1);    // destructor skipped — leak
    return 0;
}

new/delete Correctness — One Rule That Saves You

Here's the only rule you need: match new with delete, new[] with delete[]. Mix them and you get undefined behavior — corrupted heap metadata, crashes at free, silent memory corruption that surfaces three sprints later.

new[] allocates extra bytes to store the array count. delete[] reads that count to run destructors on every element. delete just frees the block without calling destructors. That's a leak. Worse, delete[] on a single object reads garbage as the count — it will try to destroy 100 million random objects before crashing.

The fix is trivial — never use new or new[] directly. Use std::vector for arrays. Use std::make_unique for single objects. Raw new/delete belong in legacy code and interview questions. Production code deserves RAII wrappers that make mismatched deletes impossible at compile time.

// io.thecodeforge — c-cpp tutorial

#include <iostream>

struct Sensor {
    int id;
    ~Sensor() { std::cout << "Sensor " << id << " destroyed\n"; }
};

int main() {
    // WRONG: new[] but delete (not delete[])
    Sensor* arr = new Sensor[3];
    arr[0].id = 1;
    arr[1].id = 2;
    arr[2].id = 3;
    delete arr;  // UB: only first destructor might run

    // RIGHT: use std::vector
    // std::vector<Sensor> sensors(3);
    // RAII handles everything

    return 0;
}

Placement new — Constructing Objects on Pre-Allocated Memory

Placement new is not an allocator. It constructs an object at a specific memory address you already own, bypassing heap allocation entirely. This is critical when you need deterministic construction in shared memory, memory-mapped I/O, or custom pools. The syntax is new (address) Type(args). You must manually call the destructor to clean up, never use delete on a placement new address because delete also calls operator delete which frees memory you didn't allocate from the heap. Placement new separates memory allocation from object construction. Use it when allocation overhead is unacceptable or memory is externally managed. The hidden cost is increased manual lifetime control. You must know exactly when to call destructors, or you leak resources inside the object. It's powerful, but one wrong destructor call corrupts your entire memory pool. Reserve placement new for performance-critical systems where every allocation counts.

// io.thecodeforge — c-cpp tutorial

#include <new>
#include <cstdlib>

struct Sensor {
    int id;
    Sensor(int i) : id(i) {}
    ~Sensor() { /* cleanup */ }
};

int main() {
    void* raw = std::malloc(sizeof(Sensor));
    Sensor* s = new (raw) Sensor(42);
    // use s...
    s->~Sensor();  // manual destructor
    std::free(raw);
    return 0;
}

Mixing new/delete with malloc()/free() — Undefined Behavior Waiting to Happen

You cannot mix malloc/free with new/delete on the same memory block. It's undefined behavior. malloc allocates raw bytes, new allocates memory and constructs objects. free releases raw memory with no destructor call, delete calls destructors then releases memory. If you malloc then delete, the object's destructor runs on memory that was never constructed, corrupting internal state. If you new then free, the destructor never runs, leaking resources inside the object. Both patterns crash or silently corrupt data. Even new and delete[] must match arrays correctly — use delete[] for array allocations. The rule is simple: pair malloc with free, new with delete, new[] with delete[]. Cross-pairing breaks the C++ object model and memory manager assumptions. Production code reviews catch this immediately. Treat any mix as an instant bug.

// io.thecodeforge — c-cpp tutorial

#include <cstdlib>

struct Data {
    int* buffer;
    Data() { buffer = new int[100]; }
    ~Data() { delete[] buffer; }
};

int main() {
    Data* d = (Data*)std::malloc(sizeof(Data));
    // d->Data();   // constructor NOT called
    // std::free(d); // okay, but leak buffer

    Data* e = new Data;
    std::free(e);   // BUG: destructor never runs
    return 0;
}

C++ new Expression — How It Differs from malloc

The new expression in C++ is not a function call but a language-level operator that integrates memory allocation with object construction. Unlike malloc, which only allocates raw bytes, new calls the constructor of the class immediately after allocating memory. This guarantees that objects are initialized to a valid state before use. Internally, new invokes operator new (which may call malloc) and then the constructor. If the constructor throws, new automatically deallocates the memory, preventing leaks. The array form new[] also tracks the number of elements to call the destructor for each one. This is fundamentally safer than malloc because it ensures construction and destruction happen correctly. When you write auto p = new MyClass(), you get a fully initialized object. With malloc, you would need placement new to achieve the same, inviting mistakes. Always prefer new over malloc in C++ code to leverage RAII and exception safety from the start.

// io.thecodeforge — c-cpp tutorial
#include <new>
#include <cstdlib>
#include <iostream>

struct Resource {
    Resource() { std::cout << "ctor\n"; }
    ~Resource() { std::cout << "dtor\n"; }
};

int main() {
    auto* p = new Resource();  // alloc + ctor
    delete p;                  // dtor + dealloc

    void* raw = std::malloc(sizeof(Resource));
    Resource* q = new(raw) Resource();  // placement new
    q->~Resource();                     // manual dtor
    std::free(raw);                     // manual dealloc
    return 0;
}

Practical Examples — Real-World Memory Management Patterns

Consider a video processing pipeline that reads frames and applies filters. Using raw new/delete leads to manual cleanup and leaks when exceptions occur. A safer pattern uses RAII wrappers like std::vector for contiguous buffers and std::unique_ptr for single objects. For example, a FilterPipeline class stores a heap-allocated kernel via std::unique_ptr<Kernel> and a frame buffer via std::vector<uint8_t>. When the pipeline goes out of scope, destructors automatically free the memory. Another pattern is custom memory pools: for thousands of small allocations (e.g., particle systems), pre-allocate a large block via operator new[] and hand out slices with placement new. This avoids repeated system calls and fragmentation. Always prefer standard containers and smart pointers over raw pointers unless performance profiling proves a bottleneck. Debug builds with sanitizers (ASan, UBSan) catch mismatches early. Write unit tests that exercise allocation-heavy paths to verify no leaks with tools like Valgrind.

// io.thecodeforge — c-cpp tutorial
#include <memory>
#include <vector>
#include <cstdint>

struct Kernel { float data[9]; };

class FilterPipeline {
    std::unique_ptr<Kernel> kernel_;
    std::vector<uint8_t> framebuf_;
public:
    FilterPipeline() 
        : kernel_(std::make_unique<Kernel>())
        , framebuf_(1024 * 768 * 3) {}
    // Destructor auto-frees memory
};

int main() {
    FilterPipeline pipe;  // no risk of leak
    return 0;
}