Orthodox C++ (2016)

Original Article ↗ Hacker News Discussion ↗

A long‑circulating blog post advocating “Orthodox C++” — a minimalist, C‑like subset of C++ that avoids exceptions, RTTI, most of the STL, and newer “Modern C++” features — reignites debate over how the language should be used. Some developers, particularly from game and embedded domains, defend this constrained style as a pragmatic way to control complexity, performance, and determinism; others argue it needlessly rejects useful abstractions like RAII, type inference, and metaprogramming that make large systems tractable. The exchange broadens into questions of language evolution, standard library design, and whether alternatives such as Rust, Zig, Nim, or even “better C” subsets of C++ offer a healthier balance between safety, expressiveness, and maintainability.

Overall reaction to “Orthodox C++”

  • Many find the article shallow or dogmatic: it lists prohibitions instead of giving nuanced guidance or rationale.
  • Others, especially from game/embedded backgrounds, say it largely reflects long-standing pragmatic practice: small subset, no RTTI/exceptions, limited stdlib.
  • Several note that C++ is inherently multi-paradigm and every serious team already chooses its own subset; “orthodox” is just one more flavor.

C vs C++ and language complexity

  • Some C programmers argue C++ adds heavy mental load: more hidden behavior, lifetime rules, and “footguns” than C.
  • Others counter that C already has plenty of hidden complexity and UB; C++ at least offers stronger typing and better abstractions.
  • A recurring theme: engineers are busy solving domain problems and don’t want to track every new C++ feature or version.

Modern features: auto, range-for, RTTI, exceptions

  • Range-based for with auto is widely defended as readable and less error-prone than iterator boilerplate.
  • Critics say auto obscures types in code reviews and diffs; proponents reply that type inference is standard in many languages and IDEs solve this.
  • Banning RTTI and dynamic_cast is seen by some as unnecessary; others call it a code smell and prefer manual or custom RTTI for performance/control.
  • Exceptions are highly contentious:
    • Anti-exception camps cite unpredictability, debugging difficulty, determinism concerns, and unclear “what can this function throw?” contracts.
    • Pro-exception voices stress they’re fine when used only for truly exceptional contract violations, not routine error handling.

Standard library, containers, and I/O

  • Strong criticism of std::map, std::unordered_map, std::deque, and even std::vector for performance, cache behavior, concurrency, and awkward APIs.
  • Others argue they’re perfectly adequate for vast amounts of real-world code; problems arise mainly in extreme high-throughput/low-latency contexts.
  • iostreams are widely disliked; many prefer C-style printf or newer fmt/<format> APIs. Some say avoiding iostream while still using type-safe formatting is the sane middle ground.

Template metaprogramming and alternatives

  • Some celebrate heavy template metaprogramming and functional styles as uniquely powerful, especially with newer constexpr/consteval/concepts.
  • Others complain about compilation times and unreadable errors, advocating sparse use.
  • Alternatives like Rust, Zig, Nim, D, and “better C” approaches are repeatedly mentioned; when choice is available, several say they’d avoid C++ entirely.