RAII Was a Mistake

Deep Copies

The first solution is obvious. Instead of doing shallow copies which leads to use-after-free bugs, we just copy everything. These "deep" copies that give us a way to free resources independently. It can't be done for everything (how do you deep copy a file handle or a socket?), but it can be done for some things (like memory). Quick example:

class CopyArray {
    int* ptr;
    size_t len;
    size_t capacity;

public:
    CopyArray(size_t initCapacity = 10) {
        assert(initCapacity > 0);
        ptr = new int[initCapacity];
        len = 0;
        capacity = initCapacity;
    }

    // Creates a new array from an existing array
    CopyArray(const CopyArray& other) {
        len = other.len;
        capacity = other.capacity;
        ptr = new int[capacity];
        for (size_t i = 0; i < len; ++i) {
            ptr[i] = other.ptr[i];
        }
    }

    // reassigns an existing arry
    CopyArray& operator=(const CopyArray& other) {
        delete[] ptr;
        len = other.len;
        capacity = other.capacity;
        ptr = new int[capacity];
        for (size_t i = 0; i < len; ++i) {
            ptr[i] = other.ptr[i];
        }
        return *this;
    }

    ~CopyArray() {
        delete[] ptr;
    }

    // ...Other methods excluded for brevity
};

Above we define two new methods, a "copy constructor" (CopyArray(const CopyArray&)), and a "copy assignment" operator (CopyArray& operator=(const CopyArray&)). These two methods will do a "deep copy," which is slow. Especially if we're accidentally introducing copies when constructing items (such as creating new items in a std::vector with push_back rather than emplace_back). So, modern C++ introduces a new pattern of "moving" or "rrefs".

Moving

C++ move semantics are different than Rust's move semantics. Unlike Rust, which actually turns off accessing the old memory, C++ doesn't. It just states that the old memory may not be valid to use anymore, but nothing actually enforces this.

Additionally, unlike Rust, C++ will still run the destructor on the old value after a move (at least in every compiler I've tested this with). I'm not sure if this was intended by the standard, but it's what I've seen happen in practice. This means that the move operator needs to set the old object to a "destructible" state (and one that isn't still pointing to the moved data). Here's an example of an array that uses move semantics.

class MoveArray {
    int* ptr;
    size_t len;
    size_t capacity;

public:
    MoveArray(size_t initCapacity = 10) {
        assert(initCapacity > 0);
        ptr = new int[initCapacity];
        len = 0;
        capacity = initCapacity;
    }

    // Creates a new array from an existing array
    MoveArray(MoveArray&& other) {
        ptr = other.ptr;
        len = other.len;
        capacity = other.capacity;
        other.ptr = nullptr;
        other.len = 0;
        other.capacity = 0;
    }

    // reassigns an existing arry
    MoveArray& operator=(MoveArray&& other) {
        // This takes advantage of the fact the
        // destructor will still be called on other.
        // Most coding standards I've seen don't like this though,
        // and they have move assignment free current
        // resources, move other's resources, and then
        // "reset" other to a null state
        std::swap(ptr, other.ptr);
        std::swap(len, other.len);
        std::swap(capacity, other.capacity);
        return *this;
    }

    ~MoveArray() {
        delete[] ptr;
    }

    // ...Other methods excluded for brevity
}

In C++, in order to differentiate between moving and copying we need to use std::move.

auto arr1 = MoveArray{10};
auto arr2 = std::move(arr1);
// arr1 shouldn't be used at this point

Of course, both of these solutions require a lot of code. What if we don't want this amount of code? Well, we can simply "disable" operators.

Disable Operators

Disabling operators is simple, we just assign the move and assignment operators to be delete.

class DisabledArray {
    int* ptr;
    size_t len;
    size_t capacity;

public:
    DisabledArray(size_t initCapacity = 10) {
        assert(initCapacity > 0);
        ptr = new int[initCapacity];
        len = 0;
        capacity = initCapacity;
    }

    !DisabledArray() { delete[] ptr; }

    DisabledArray(const DisabledArray&) = delete;
    DisabledArray&(const DisabledArray&) = delete;
    DisabledArray(DisabledArray&&) = delete;
    DisabledArray& const operator=(DisabledArray&&) = delete;
}

This will prevent copies and moves of a class, so when we pass instances of it around we have to pass it by reference (either with pointers or references).

This also brings up an important point of the other example solutions. Since we only defined a move or copy behavior, we need to disable (or define) the other behaviors as well. In other words, we need to make the following changes:

class CopyArray {
    // ... Rest of the code is the same
public:
    CopyArray(CopyArray&&) = delete;
    CopyArray& operator=(CopyArray&&) = delete;
}

class MoveArray {
    // ... Rest of the code is the same
public:
    MoveArray(const MoveArray&) = delete;
    MoveArray& operator=(const MoveArray&) = delete;
}

When to Define Copy and Move

When do we define (or delete) copy and move? Anytime we define a destructor. Which is another way to say anytime we use RAII.

That's a lot of overhead and work to use RAII. There are workarounds, such as smart pointers (shared and unique) to help conditionally turn off RAII. But, they require memory allocations and don't help with variables on the stack. We still have to do solve for variables that don't live in the heap.

The mental and coding overhead of RAII makes working with RAII in C++ tiresome, cumbersome, and bug-prone - which is ironic for a feature meant to reduce bugs. So, is there a different way to do RAII? Yes, let's look at Rust.

Defer

Defer will take a statement or expression, and defer it's execution until some future point in time (usually at the end of the block scope - unless you're Go). This allows us to write the cleanup code right next to the instantiation code, like so:

// Psuedo-code showing defer
var fileHandle = fopen("example.txt", "r");
defer fclose(fileHandle);

Zig also introduces the idea of errdefer, which only executes a block of code if there was an exception. This is primarily helpful for allocation methods which allocate a resource (e.g. open a file handle), and then return that resouce on a success. If something goes wrong before the resource is returned, errdefer allows it to be easily cleaned up.

// Psuedo-code showing errdefer
fn openExample() !FileHandle {
    var fileHandle = fopen("example.txt", "r");
    errdefer fclose(fileHandle);
    if (fsize(fileHandle) < MIN_FILE_SIZE) {
        return error(FILE_TOO_SMALL);
    }
    return fileHandle;
}

The above code is clear (as in easy to review and debug), explicit, and known to be "bug-free." Defer is magical.

And the magic of defer boils down to that it's the direct inverse of RAII.

With RAII, you have to opt-out of automatic cleanup. With defer, you have to opt-in. With RAII, the clean-up is hidden from the developer with magically inserted commands. With defer, the clean-up is explicit to the developer with visible and documented commands. With RAII, you're having to work around unwanted commands inserted by the compiler through copies, references, and move semantics. With defer, you're working with the compiler to only insert the commands you want.

Defer ends up simplifying code a lot. Shallow copies work well since the developer knows (and picks) which copy gets cleaned up. Move semantics aren't needed since a move boils down to a shallow copy where the copy is cleaned up, not the original. Zig's errdefer also provides some much welcome semantic sugar when it comes to error handling.

Personally, I find defer to be really useful, especially when combined with good debug tooling - like automatic memory leak detection and reporting. I've found most languages lack good debug tooling in the standard distributions, so it usually needs to be built. Fortunately, the most useful tools are pretty basic and aren't too hard to build. For C++, I just have my own allocator class I pass around. Under the hood, it's just a wrapper for malloc but adds memory allocation tracking. It's not that hard to wrap other resources either.

Fortunately, defer isn't the only option, just what I found to be the most compelling. I'll cover some other options as well.

Arenas and "Action Based Lifetimes"

Another tool to use are arena allocators. Arena allocators are generally used for memory management. They allow allocating more and more memory, and then instead of freeing individually you free all at once.

struct SomeTask {
    String input;

    // Pass in the arena so we can do memory allocations
    void run(ArenaAllocator arena) {
        // use the arena
        CharBuffer buffer = input.toBuffer(arena);
        val parser = arena.new<IntBufferParser>();
        List<int> parsedInts = parser.parse(arena, buffer);
        println(parsedInts.join(arena, ", "));
        // We didn't have to free anything because the arena takes care of the freeing
    }
}

class TaskManager<T> {
    Queue<T> tasks;

    void processTasks() {
        while (!tasks.empty()) {
            T task = tasks.pop();
            // create an arena for the task to use
            ArenaAllocator arena = ArenaAllocator();
            try {
                task.run(arena);
            }
            finally {
                // here we clean up the arena which cleans up all task memory
                arena.freeAll();
            }
        }
    }
}

val taskManager = TaskManager();
taskManager.tasks.push(SomeTask("1 23 43 69"));
taskManager.processTasks();

We aren't restricted to a single task layer either. We can layer the task-based lifetimes.

A game is going to have resources used for the entire time the application is opened (such as the OS window), resources loaded for a specific phase (playing game or in main menu), resources for a specific level, and resources for a specific frame. Each of those levels are separate "tasks" which get their own arena. They are freed when each task is done. And if an arena is based off of a parent arena, we can clean everything up by just clearing the parent arena. Pretty cool.

Arenas are much easier to implement than defer. They can often be made as a library rather than changing the compiler, which makes them really nice to try out. That said, there are some drawbacks.

First, resources become task-based, and it takes care to ensure they stay tied to that task. If you create an array in an HTTP request arena, you can't just pass that array to a background task scheduler, otherwise the memory will be cleaned up before the task runs. Instead, you have to introduce additional copies whenever you transition from one task context to another.

Of course, alternatives don't have to be limited to what actually exists. What I've shown are both still really manual, and some people may want a more "automated" alternative. I have a theoretical alternative, but I'm unaware of any language which currently offers it.

Actual Garbage Collection

I'm not going to state whether garbage collection is good or bad. But what I am suggesting is that it's really wierd that "garbage collection" is limited to only memory allocations, not file handles, sockets, or any other resources you might care about. An actual, true garbage collector should keep track of those other resources too - or at least any resources you have to reserve from the host operating system.

But, isn't GC automatically cleaning up memory similar to RAII?

No. RAII is a compile-time process which inserts invisible instructions when the program is built. Those instructions always execute, whether or not it's correct. It errs on the side of aggression as RAII languages believe it's worse to leak than to double free. This then makes it the responsibility of developers to fix the compiler's mistakes.

In contrast, GC is a run-time process which does a lot of runtime checks to ensure a resource is definitively not used before being cleaned up. It errs on the side of caution. As a result, developers don't have to think about if a GC is going to insert a buggy use-after-free or double-free condition. Sure, it slows down the program and results in memory staying around longer than necessary, but it's proven itself really valuable for dozens (if not hundreds) of programming languages over the years.

My main point here is to say, if so many languages claim that GC works super well, and if so many developers rely on GC for memory management, why aren't we extending it to all resources? Why doesn't Java know what a file handle is, and keeps track of when it becomes an unreferenced file handle? Java already does it for pointers, why not file handles too? Why not network sockets? Why do these languages mandate developers need to track those resources?

I think if we want the next mainstream way of managing resources, a GC that manages everything is a really good way to do that.