Smart Pointers for Heap Management

1. The Problem with Manual Memory Management

In C++, you can allocate memory on the stack or on the heap. Stack memory is automatic—when a variable goes out of scope, its memory is automatically reclaimed. Heap memory, allocated with new, is not. You are responsible for freeing it with delete. Forgetting to do so causes a memory leak. Deleting it more than once causes undefined behavior, which often leads to a crash.

Managing new and delete manually becomes very difficult in complex applications where pointers to objects are passed around. Who is responsible for deleting the object? When is it safe to do so? Smart pointers solve this problem by wrapping a raw pointer and using a C++ feature called RAII (Resource Acquisition Is Initialization). The core idea is simple: the smart pointer "owns" the object, and when the smart pointer itself is destroyed (e.g., when it goes out of scope), its destructor automatically calls delete on the raw pointer it manages.

To see why this is so important, let's watch a quick introduction.

There are two main types of smart pointers we'll focus on, each representing a different kind of "ownership."

2. std::unique_ptr: Exclusive Ownership

The simplest smart pointer is std::unique_ptr. It enforces a strict, exclusive ownership model: only one unique_ptr can own a given object at any time. It's incredibly lightweight, having no performance or memory overhead compared to a raw pointer.

Because of this strict ownership, you cannot copy a std::unique_ptr. If you could, you'd have two unique_ptrs that both think they own the object, and both would try to delete it upon destruction.

However, you can move a unique_ptr, which transfers ownership from the source to the destination. After the move, the source unique_ptr becomes empty (null).

To use smart pointers, you need to include the <memory> header.

#include <memory>
#include "MyObject.h" // Assume we have a class MyObject

// The preferred way to create a unique_ptr
std::unique_ptr<MyObject> ptr1 = std::make_unique<MyObject>();

// ptr2 now owns the object. ptr1 is now null.
std::unique_ptr<MyObject> ptr2 = std::move(ptr1); 

// This will cause a compile error:
// std::unique_ptr<MyObject> ptr3 = ptr2; // Error: unique_ptr cannot be copied.

// When ptr2 goes out of scope, the MyObject it owns is automatically deleted.

Let's see unique_ptr in action.

3. std::shared_ptr: Shared Ownership

Exclusive ownership is great, but sometimes you genuinely need multiple parts of your application to co-own an object. For instance, in a scene graph, several nodes might reference the same material or texture. If any one of them were the exclusive owner, the resource might be deleted while others still need it.

This is where std::shared_ptr comes in. It allows for shared ownership of a resource. It works by using a technique called reference counting.

A small, hidden data structure called a "control block" is allocated alongside the object. This control block contains a counter that tracks how many shared_ptrs are currently pointing to the object.

• When you create a new shared_ptr by copying an existing one, the reference count is incremented.
• When a shared_ptr is destroyed (or reset), the count is decremented.
• When the count reaches zero, it means no shared_ptrs are left pointing to the object, and it is safely deleted.

The syntax is very similar to unique_ptr. The preferred way to create a shared_ptr is with std::make_shared. This is more efficient than creating the object with new and then passing it to a shared_ptr constructor, because make_shared can allocate the memory for both the object and its control block in a single operation.

#include <memory>
#include "MyObject.h"

// Create a shared_ptr. Ref count is now 1.
std::shared_ptr<MyObject> s_ptr1 = std::make_shared<MyObject>();

{
    // Create a copy. Ref count is now 2.
    std::shared_ptr<MyObject> s_ptr2 = s_ptr1;
    std::cout << "Ref count inside scope: " << s_ptr1.use_count() << std::endl; // Prints 2
} // s_ptr2 goes out of scope, ref count becomes 1.

std::cout << "Ref count outside scope: " << s_ptr1.use_count() << std::endl; // Prints 1

// When s_ptr1 goes out of scope, the ref count becomes 0, and the object is deleted.

Let's watch the final segment of the video to see this in practice.

#include <memory>

void take_ownership(std::unique_ptr<int> p) {
    // ... does something with p
}

void share_ownership(std::shared_ptr<int> p) {
    // ... does something with p
}

int main() {
    auto u_ptr = std::make_unique<int>(10);
    auto s_ptr = std::make_shared<int>(20);

    // Which of the following lines will compile, and which will fail? Why?
    // Line 1
    take_ownership(u_ptr);
    
    // Line 2
    share_ownership(s_ptr);

    // Line 3
    if (u_ptr) { /* do something */ }

    return 0;
}

4. Smart Pointers in Our Ray Tracer

Now, let's connect this back to std::vector<shared_ptr<hittable>>. To understand the design choice, we can look at the Ray Tracing in One Weekend text.

As the text explains, using std::shared_ptr in our hittable_list gives us two major benefits:

1. Polymorphism: The vector can hold pointers to any object that inherits from hittable (spheres, triangles, etc.). This allows us to build a flexible scene with different types of geometry.
2. Automatic Memory Management: When our hittable_list is destroyed, its vector of shared_ptrs is also destroyed. This automatically handles decrementing the reference counts and deleting any objects that are no longer referenced, preventing memory leaks without any manual cleanup code.

Furthermore, shared_ptr is essential for another reason that will become important soon: sharing materials. In a complex scene, you might have hundreds of objects that all use the same material (e.g., "red plastic"). Instead of creating a separate material object for each one, we can create a single material instance and have all the relevant objects point to it using a shared_ptr. This is efficient and allows for easy updates.

The text also shows this in practice, by adding a material pointer to the sphere class.

5. unique_ptr vs. shared_ptr: Which Should I Use?

With two types of smart pointers, it's natural to ask which one is better. Here's the standard C++ guideline:

1. Default to std::unique_ptr. It perfectly represents the common case of a single owner. It's simple, fast, and has no overhead. It clearly communicates your design intent: this pointer is the sole owner of this resource.
2. Use std::shared_ptr only when you explicitly need shared ownership. If you can't identify a single owner for an object's lifetime, then shared_ptr is the correct tool. The reference counting has a small performance cost, so you should only pay it when necessary.

A brief note on an advanced topic: shared_ptr can lead to circular references, where two objects hold shared_ptrs to each other. This prevents the reference count from ever reaching zero, causing a memory leak. C++ provides std::weak_ptr to break these cycles, but that is a more advanced tool for specific situations.

Key Takeaways

• Smart pointers are C++ objects that wrap raw pointers to automate memory management, preventing leaks and other bugs.
• They work on the principle of RAII: resource lifetime is tied to the scope of the smart pointer object.
• std::unique_ptr provides exclusive ownership. It is lightweight but cannot be copied, only moved. This should be your default choice.
• std::shared_ptr provides shared ownership via reference counting. It can be copied and is used when multiple owners need to manage an object's lifetime.
• Always prefer std::make_unique and std::make_shared to create smart pointers.

Next Steps

You've now covered the core C++ tools for managing objects and collections: std::vector and smart pointers. We have one final foundational lesson before we can start rendering our first image. In the next lesson, you will learn how to write image data to files using std::ofstream. This will allow us to save the output of our ray tracer as an image file that we can view.