Recently, Herb Sutter wrote an excellent article on C++ safety. He discussed numerous ideas, but I’ll provide a summary of his perspective on what can be done in the medium term to enhance C++ safety.
| In C++, by default enforce … | (A) Solution for new/updated code (can require code changes — no link/binary changes) | (B) Solution for existing code (requires recompile only — no manual code changes, no link/binary changes) |
| Type safety | Ban all inherently unsafe casts and conversions | Make unsafe casts and conversions with a safe alternative do the safe thing |
| Bounds safety | Ban pointer arithmetic Ban unchecked iterator arithmetic | Check in-bounds for all allowed iterator arithmetic Check in-bounds for all subscript operations |
| Initialization safety | Require all variables to be initialized (either at declaration, or before first use) | — |
| Lifetime safety | Statically diagnose many common pointer/iterator lifetime error cases | Check not-null for all pointer dereferences |
| Less undefined behavior | Statically diagnose known UB/bug cases, to error on actual bugs in existing code with just a recompile and zero false positives: Ban mathematically invalid comparison chains (add additional cases from UB Annex review) | Automatically fix known UB/bug cases, to make current bugs in existing code be actually correct with just a recompile and zero false positives: Define mathematically valid comparison chains Default return *this; for C assignment operators that return C& (add additional cases from UB Annex review) |
But what are the current possibilities for achieving this goal?
Continue reading “Could Herb Sutter’s call to action for C++ safety be acheived soon?”