A pointer can still hold an address after the object at that address has been destroyed. Dereferencing it is a use-after-free bug: a plausible-looking address does not mean the object is alive. To avoid that mistake, keep track of who owns each object, when its lifetime ends, and whether any borrowed access could outlast it.
Start with ownership, not allocation syntax
An owner keeps an object alive and eventually releases it. A non-owning pointer or reference can access the object but does not extend its lifetime. When those roles are hard to tell apart, choose types that make ownership visible.
For a local value, start with an ordinary object: std::string name;. For a sequence whose size can change, use std::vector. Choose std::unique_ptr when an object needs a single, transferable owner and holding it by value is impractical. Use std::shared_ptr only when multiple owners really must control its lifetime together—not just because several functions need to see it.
These choices use RAII: an object acquires a resource, and its destructor releases it. That resource might be heap memory, a file handle, or a lock. Cleanup follows the owner's lifetime, even if a function exits through an exception. The RAII explanation explains why this link between object lifetime and cleanup matters in C++.
Pitfall 1: Manually pairing new with delete
Every call to new needs a matching delete. An early return, an exception, or a later edit can skip it. This code has that problem:
Widget* widget = new Widget();
configure(*widget); // May throw.
use(*widget);
delete widget;If configure throws, the final line never runs. When the object needs dynamic storage, give ownership to a local std::unique_ptr:
auto widget = std::make_unique<Widget>();
configure(*widget);
use(*widget);The unique_ptr destroys the Widget when it leaves scope. If there is no reason to allocate dynamically, Widget widget; is simpler. An ownership tool is not a reason to put every object on the heap.
Arrays need a container, not a manual cleanup rule
Pairing new[] with delete, or new with delete[], is undefined behavior. Instead of tracking which form to call, put a variable-length sequence in std::vector<T>. It owns its elements, tracks its size, and releases its storage when destroyed. For a fixed size known at compile time, use std::array<T, N>. Memory allocated by a C API may need its own release function; wrap it with the API's correct cleanup operation rather than assuming C++ delete applies.
Pitfall 2: Assuming a pointer keeps an object alive
A raw pointer can be a useful non-owning view, but it says nothing about how long the object will live. Suppose a function returns local.c_str(), where local is a std::string declared inside that function. On return, the string is destroyed and the pointer dangles. Return the std::string by value instead; C++ supports efficient value returns without giving callers an invalid view.
A similar bug appears when a function saves a reference or std::string_view to a temporary argument for later use. Views avoid copying; they do not own the data. If the data must survive the call, store an owning std::string or state the required lifetime explicitly in the interface.
Deleting an object through one pointer leaves every other pointer to it dangling. Setting that pointer to nullptr does not change its copies, and a non-null check cannot prove the object is alive. Keep ownership in one place, then pass references or non-owning pointers for work that finishes during the owner's lifetime.
Pitfall 3: Keeping references into a changing container
A container can remain alive while its elements move or disappear. When a std::vector grows, it may reallocate, invalidating pointers, references, and iterators to its elements. Erasing elements can invalidate them too. Here, the insertion may make first unusable:
std::vector<int> values{10, 20};
int* first = &values[0];
values.push_back(30);
// Do not assume first still points to values[0].Retrieve the element again after insertion if it still exists. An index may work better than a pointer, but code using it still has to account for insertions, removals, and bounds changes. reserve prevents growth-related reallocation up to the reserved capacity; it does not guarantee that every later operation preserves every reference. Check the invalidation rules for the container and operation you use.
This is not just a vector problem. A std::string_view into a string can become invalid when the string changes or dies. A reference to an erased map element is invalid even if the map's other elements remain. Trace the lifetime of the particular object being referenced, not only its container.
Pitfall 4: Choosing shared ownership without a lifetime reason
A std::shared_ptr keeps an object alive while at least one owning instance remains. That solves some ownership problems, but reference counting has a cost and can make destruction harder to predict. Passing a shared_ptr to a function that only needs to inspect an object also lets that function retain ownership. If it should not do so, pass a reference or an appropriate non-owning pointer.
Cycles defeat reference counting
Two objects holding shared_ptr instances to each other can keep each other alive after every outside owner is gone. In a parent-child structure, the parent might own the child through shared_ptr, while the child holds a std::weak_ptr back to the parent. The weak pointer does not increase the ownership count. Before using the parent, call lock() and check whether it succeeded.
weak_ptr is not a general replacement for raw pointers. It works with objects managed by shared_ptr and helps an observer detect expiration. When the owner's lifetime is already guaranteed, a short-lived borrowed reference may be simpler.
Pitfall 5: Mishandling copy and move behavior
Copying an owning raw pointer copies its address, not the object. If both copies call delete, the program tries to free the same object twice. If neither does, the object leaks. A class that directly manages a resource needs deliberate copy, move, and destruction behavior.
Prefer the rule of zero: keep resources in standard-library members that already manage their lifetimes, and let the compiler generate the surrounding class's operations. A class containing a std::vector can usually be copied as a value. One containing a std::unique_ptr is non-copyable by default but can typically be moved. If copying must create an independent owned object, implement that behavior explicitly instead of copying the pointer address.
Moving can transfer a resource or value, but the moved-from object still exists until its lifetime ends. Its state remains valid, though it may no longer hold its previous value. Do not assume its old data is unchanged; assign it a new value or use only operations its type permits in that state.
Pitfall 6: Confusing allocation success with safe size calculations
A memory bug can start before allocation. If a size calculation overflows, the allocated buffer may be smaller than the data later written into it. When multiplying an untrusted item count by an item's size, check that the product fits in std::size_t before allocating. A vector often removes the need to calculate byte counts manually, but application limits still matter: an enormous valid count can exhaust memory.
Check counts against a sensible maximum before resizing a container. If a count comes from a file or network message in an authorized project, confirm that enough input remains for the claimed elements before processing them. That check is separate from whether the count's text parsed correctly.
Also watch arithmetic near the end of a buffer. offset + length <= data.size() can overflow before the comparison. First establish offset <= data.size(); then test length <= data.size() - offset. Use suitable unsigned size types for lengths and offsets, and handle negative external values before converting them.
A practical review and testing routine
When reviewing a function that manipulates memory, write its ownership contract in plain language. Searching for new alone will miss borrowed views and container invalidation. Check the following:
- Identify the owner. For each allocated object or external resource, find the value responsible for releasing it.
- Mark borrowed access. Check whether a pointer, reference, iterator, or view could survive its owner or a container mutation.
- Trace every exit. Include exceptions, failed validation, early returns, and cancellation paths.
- Inspect copy and move. Decide whether copying creates an independent resource, intentionally shares ownership, or must be prohibited.
- Test boundaries. Try empty inputs, maximum allowed counts, insertion that grows a container, and failures during construction.
Compiler warnings help, but they cannot prove that every lifetime is correct. During development, use a separate test configuration with AddressSanitizer to help find use-after-free and out-of-bounds accesses. Where available, LeakSanitizer can report unreleased allocations, and UndefinedBehaviorSanitizer can catch some other undefined behavior. These tools report bugs on paths your tests execute, so include error paths and container growth in small tests. They do not replace a clear ownership design.
For one focused test, start with a vector that has a small initial capacity. Keep no long-lived pointers to its elements, append enough values to force growth, and verify the results by indexing the current vector. Then test an empty input and a rejected oversized count. This exercises changing storage and the application's size limit without depending on an address that happens to stay stable.
