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_mapandvector::reservesemantics). - 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.