With smart pointers now standard practice, it is reasonable to ask whether C++ memory management still deserves a book-length, systematic treatment. Avoiding direct new and delete calls does not automatically make borrowed references or byte-level access safe.

On August 17, 2026, the ISO C++ Blog highlighted Sandor Dargo’s review of Patrice Roy’s book. The post calls out a range from object lifetime fundamentals to C++26 and uses the aliasing role of char* as one of its central examples.

The useful question is therefore larger than allocation and deallocation: who owns the object, how long does it live, and through which type may its representation be observed? Those layers explain why the topic remains current.

Smart pointers do not automatically define every object lifetime

Packt published C++ Memory Management in March 2025. Its official description spans object lifetime and memory organization, allocation machinery, custom containers and allocators, and the constraints of real-time, game, and embedded systems. At 442 pages, it is positioned as more than a catalog of smart-pointer APIs.

C++ Core Guidelines R.1 and R.20 recommend managing resources through RAII handles and using unique_ptr or shared_ptr when ownership needs to be represented. That is a strong starting point, but it does not extend the lifetime of a non-owning span, reference, or iterator.

#include <array>
#include <cstddef>
#include <span>

/**
 * Summary: Returns a view into a local array as a deliberately unsafe example.
 * Parameters: None.
 * Returns: A std::span<const std::byte> that becomes invalid when the function returns.
 * Exceptions: Does not throw.
 * Complexity: O(1).
 * Caution: The array lives only inside the function, so the returned view dangles.
 */
std::span<const std::byte> createDanglingView() noexcept {
  // A view does not own data and therefore cannot outlive the source array.
  std::array<std::byte, 1024> storage{};
  return std::span<const std::byte>(storage);
}

There is no new or delete here, yet the returned span is unusable because storage dies at function exit. Systematic memory-management study is valuable precisely because it puts these non-owning lifetimes in the same model as allocation.

char serves both character data and raw object representation

Although its name suggests text, char also has a special role in examining object representation. The current C++ working draft permits the underlying bytes of an object to be copied into arrays of char, unsigned char, or std::byte.

Because of this exception, a compiler cannot simply assume that access through char is unrelated to an object of another type. That is why the review’s discussion of char* and optimization is about more than legacy string APIs: it reaches type-based alias analysis.

C++17 introduced std::byte to represent a byte as neither a character nor an arithmetic integer. Proposal P0298R3 defines it as a distinct type with bitwise operations but without implicit numeric conversions. Using char for text and std::byte for binary buffers makes an API’s intent easier to read.

Replacing char* with std::byte* does not, by itself, remove aliasing or guarantee faster code. Both types are permitted to access object representation; the immediate benefit of std::byte is semantic clarity.

C++23 and C++26 keep changing how memory concepts are expressed

The review also mentions the C++23 feature often called “deducing this” as a way to reduce duplication in begin() and end() implementations. The formal mechanism in P0847R7 is the explicit object parameter, and its application to the working draft was approved at the October 2021 WG21 meeting. C++23 itself was published in October 2024 as ISO/IEC 14882:2024.

The erroneous behavior treatment of uninitialized reads belongs to C++26. P2795R5 introduces a category for incorrect code whose behavior is nevertheless constrained by the specification and for which implementations are encouraged to diagnose the error. The Tokyo meeting record N4982 records the vote to apply that change to the working paper.

The version boundary matters. The June 2026 editors’ report N5051 describes N5050 as the final C++26 working draft and the basis for the Draft International Standard. As of August 18, 2026, C++26 is therefore well advanced but not yet a published International Standard.

This distinction lets us value a book’s coverage of recent specification work without confusing that currency with immediate production availability. Memory management is a classic topic, but the language used to explain it is still evolving.

The book fits readers making design decisions below the ownership layer

The official chapter outline moves from foundations toward custom memory machinery. Its scope aligns most closely with readers who need more than a refresher on RAII: they also need to understand why a container or allocator is designed a certain way and how a target architecture changes the tradeoffs.

That includes work where you need to:

• track the lifetime of span, references, and pointers separately from ownership
• handle object representation in binary formats, networking, or device I/O
• control allocation timing or predictability in real-time, game, or embedded software
• understand post-C++23 features in relation to existing designs rather than as isolated syntax

If the immediate goal is simply to use RAII and standard containers safely in application code, applying the Core Guidelines may be the shorter first step. Custom allocators and low-level optimizations become useful only after the project’s actual constraint is clear.

Memory management is the design of meaning and lifetime, not cleanup alone

The opening question has a clear answer: smart pointers do not remove the value of studying memory management systematically. The goal is not to collect more techniques for manual deallocation. It is to place ownership, lifetime, object representation, and allocation strategy on one map.

That is also the significance of the review’s path from the familiar char* to C++26’s erroneous behavior. In everyday code, the next useful question after “who owns this?” is “when does this view become invalid, and what type gives meaning to these bytes?” Once those questions are connected, memory management becomes part of API and data design rather than low-level cleanup after the fact.

Source

• Title: Book Review: Memory Management in C++ by Patrice Roy -- Sandor Dargo
• URL: https://isocpp.org//blog/2026/08/book-review-memory-management-in-cpp-by-patrice-roy-sandor-dargo