21st Century C++

Code formatting and ACM presentation

  • Many comments focus on the article’s terrible code typography: proportional fonts, collapsed indentation, and broken spacing make examples hard to read.
  • Some blame the author’s traditional preference for variable-width fonts; others insist this is an ACM HTML/CSS bug, not the author’s choice.
  • Several note the rendering differs by browser and font settings; for some it was fine with a proper monospace default, others saw it fixed only after the site was updated.
  • People question how a major computing society can ship code examples with such poor formatting; several point to the author’s own PDF as “massively better.”

Modules, templates, and compilation

  • Readers are interested in modules for compile-time improvements, but note modules don’t solve duplicate template instantiations.
  • Discussion covers “extern template,” the abandoned “export” templates, and manual explicit instantiation as ways to reduce template bloat.
  • Multiple commenters stress that, despite being standardized in 2020, modules are still rough: compiler bugs, incomplete tooling (especially CMake), and hard migration for large projects.

Guidelines, tooling, and “modern C++” subsets

  • Newcomers are confused by the recommended path: Core Guidelines + GSL + compiler/linter tooling.
  • Tools like clang-tidy, CLion, and MSVC analyzers have partial guideline enforcement; but full, compiler-level enforcement of the Core Guidelines does not exist.
  • There’s broad agreement that in real codebases people effectively choose a “subset of C++,” but heavy disagreement on which subset is appropriate and how much of the language is “for library writers” vs. application code.

Memory safety, profiles, and Safe C++

  • One camp argues C++ can’t become truly memory safe without breaking changes and that “profiles” won’t be enough.
  • Another camp, working on very large legacy codebases, says full rewrites (to Rust or a new C++) are economically impossible; any incremental safety (profiles, future “Safe C++”) is valuable.
  • Debate over borrow-checker-style proposals: strong safety is seen as incompatible with much existing C++ (especially pointer-heavy APIs), though experimental compilers like Circle are cited as counterexamples, with pushback that they still require large code changes to benefit.

Backwards compatibility vs. language evolution

  • Some see C++’s extreme backward compatibility as its defining strength (3M–10M+ LOC, decades-old code still compiles).
  • Others argue this same compatibility prevents fixing core problems (UB, unsafe containers, awkward standard-library designs like unordered_map and vector::reserve semantics).
  • Comparisons with Java, Go, and Python highlight differing experiences with breaking changes; opinions vary widely on which ecosystems handle compatibility better.

C++ in practice and career considerations

  • Multiple practitioners report large, active C++ use in HFT, embedded systems, game engines, AI backends, and big tech; others note partial or total bans in some companies in favor of Rust.
  • Prospective systems programmers ask whether C++ is still required; answers say C++ dominates many professional settings and is far more common than C, while Rust skills transfer but don’t replace C++ everywhere.
  • Job-market impressions: demand is strong but concentrated; some roles pay very well, others less than equivalent work in “easier” languages.

Reactions to the article and language direction

  • Several readers appreciate the article’s self-awareness and attempt to highlight “good parts” of modern C++ and a safer style, but others find the code style ugly and the examples flawed (including UB from signed overflow in the first program).
  • There’s fatigue with the language’s growing complexity, new features (ranges, coroutines, concepts) perceived as “messy” or hard to justify learning vs. switching to another language.
  • A recurring theme is a love–hate relationship: people respect C++’s power and longevity, but many now reach for Rust, Swift, Go, or higher-level languages unless C++ is clearly required.