C++ Safety, in Context

Committee, process, and safety features

• Many commenters are frustrated that good safety ideas exist but standardization is slow and inconsistent (e.g., std::span shipped without .at() until C++26, operator[] remains unchecked).
• Clarification that the C++ committee mainly ratifies proposals backed by working implementations; it cannot unilaterally “impose” a new C++.
• Backward compatibility and ABI stability are seen as dominant constraints that block deeper safety changes (e.g., fat pointers, breaking syntax, epochs).

Culture and default unsafety

• Several stories of teams disabling sanitizers, ignoring ASAN reports, refusing debuggers, and treating out-of-bounds access as acceptable if it “doesn’t crash.”
• Some argue this is fundamentally an attitude problem: tools already exist but many developers and orgs won’t use them unless strongly incentivized or punished.
• Others counter that not all software needs the same level of hardening, but critics reply that any network‑connected app can become part of an exploit chain.

Bounds checking and performance tradeoffs

• There is recurring debate over default bounds checks: should operator[] abort, throw, or remain unchecked; should safety be on by default with an explicit unsafe_* escape hatch.
• Some argue overhead is small in practice (citing system-level measurements) and worth it; others emphasise HPC/embedded workloads where even a few percent regression matters.
• Historical excuses (“too slow in 1990”) are seen as less valid today, but some still prioritize performance over safety.

CVEs, metrics, and filesystem race example

• Strong disagreement over using raw CVE counts to compare C/C++ to Rust: severity differs, and language communities set different bars for what gets a CVE.
• Example: a filesystem TOCTOU issue got a Rust CVE and blogged fix; C++ standard libraries quietly patched similar bugs but did not file CVEs, while the C++ spec labels filesystem races as undefined behavior.
• Some worry C++ actors might “manage” CVE counts instead of fixing root causes; others say the issue was handled responsibly even without a CVE.

Comparisons with Rust and other languages

• Many see Rust as a qualitative step up: memory safety by default, encapsulated unsafe, better thread-safety guarantees, and a culture that treats safety as primary.
• Counterpoints: Rust still has CVEs; many Rust crates use unsafe (often for FFI); safe Rust struggles with some data structures without indirection (arenas, Rc/Arc, indices).
• Some stress that memory safety is only one vulnerability class; memory‑safe languages still suffer from logic bugs, injection, secrets handling, etc., but others argue removing a huge class of bugs is still a “good problem to have.”

Government, industry pressure, and future of C++

• Recent government and large‑vendor reports urging a move away from memory‑unsafe languages are seen as a key backdrop; some read the article as a defensive response.
• Debate over whether C++ can realistically reach “parity” with memory‑safe languages via non‑breaking changes and tooling versus needing radical, breaking shifts (epochs, safe subsets, or “Typescript-for-C++” approaches).
• Many believe legacy C++ will persist for decades, so better tools and safer modes still matter even if new projects migrate to Rust, Go, etc.

Cognitive load and project choices

• Multiple posts describe modern C++ as cognitively exhausting: complex syntax, heavy template errors, many overlapping features, and subtle UB.
• Some say they still use C++ only because of legacy code, ecosystem, or domain norms (HPC, game engines), and would otherwise prefer Rust or other languages.
• Overall mood: C++ can be made safer at the margins, but for new greenfield work, many commenters would avoid it if they can.