Modern C++ – RAII

Original Article ↗ Hacker News Discussion ↗

RAII vs other resource-management patterns

  • RAII is praised for deterministic, automatic cleanup tied to scope, not to explicit “using/try/defer” blocks. Once constructed, destruction is guaranteed (barring abnormal termination) and ordering is clear (reverse of construction).
  • Critics argue other languages solve the same problem “differently and often better”: Java’s try-with-resources, C# using, Kotlin use, Go defer, Python with, Swift defer, and linear/ownership types (Rust, Austral).
  • Pro‑RAII commenters counter that these constructs are more error‑prone because they require explicit syntax at every use site and often need static analysis to enforce correct use, whereas RAII is at the type/implementation level.
  • Debate over whether RAII is “modern”: some note it has existed in C++ since early 1990s; “modern” mostly refers to the combination of RAII with move semantics and stdlib smart pointers introduced in C++11 and refined later.

C++ vs Rust and other languages

  • Some see C++ in 2025 as mostly for legacy systems and game engines; others point to a broad ecosystem of high-performance libraries and applications still written in C++.
  • Rust is frequently cited as having superior resource and lifetime management (ownership, linear types, “destructive” moves), with RAII-like behavior baked into the language model.
  • There is disagreement about productivity and salaries, and whether Rust’s current advantage is fundamental or partly due to being a newer language without legacy baggage.
  • Comparison with C: some prefer modern C for libraries and interop; others list C++ features (templates, references, RAII, constexpr, stdlib) as decisive advantages.

Practical RAII usage, pitfalls, and tooling

  • Many note RAII is most often implemented in libraries (especially the standard library); most application code just uses those abstractions rather than writing custom destructors/move constructors.
  • Misuse risk exists: forgetting parts of the “rule of 3/5” or special members can break invariants; strong warning flags (e.g., -Wall -Wextra -Wpedantic, plus more specialized ones) and static analysis are recommended.

shared_ptr vs unique_ptr and stack allocation

  • Consensus pattern: stack allocation by default; unique_ptr for heap allocation; shared_ptr only when true shared ownership is unavoidable.
  • Reasons to avoid shared_ptr by default:
    • Costs: atomic reference counting, many tiny heap allocations, poorer cache locality; for heavily heap-bound workloads, tracing GC languages may outperform.
    • Semantics: ownership becomes unclear, lifetimes are hard to reason about, cycles can leak, destruction may be unexpectedly delayed.
  • unique_ptr is viewed as far easier for reasoning about lifetimes and often zero-cost after construction; overuse of heap still harms locality.

Limitations and edge cases of RAII

  • Using destructors for cleanup means you generally cannot signal errors from cleanup (e.g., close() failure) without dangerous exception behavior; standard file streams historically ignore such errors on destruction.
  • Some address this by explicit close/discard/deinit methods and “empty” destructors that only assert correct use, but this weakens the RAII guarantee.
  • shared_ptr exacerbates this: destruction (and thus cleanup) may occur long after logical end-of-use because references persist elsewhere.