Tag: C++ Committee

Another big tech company join the move away from C++ initiative, How we can stop this migration process?

Background

2011 marked the renaissance of C++, driven by the release of C++11 which introduced numerous features to modernize the language, such as lambda expressions, smart pointers, and a more efficient standard library. However, a decade later, major tech giants like Google, Microsoft, Amazon, Apple, and Meta are initiating processes to migrate away from C++. This shift highlights growing concerns about memory safety and the evolving landscape of systems programming.

Just recently there’s another big company joining the Moving away from C++ initiative. it concern Apple that recommend to replace C++ with Swift.

One could argue that the issue lies not with C++ itself, but with the developers using it. However, the reality is that big companies are shifting away from C++.

Continue reading “Another big tech company join the move away from C++ initiative, How we can stop this migration process?”

Could Herb Sutter’s call to action for C++ safety be acheived soon?

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 safetyBan all inherently unsafe casts and conversionsMake unsafe casts and conversions with a safe alternative do the safe thing
Bounds safetyBan pointer arithmetic Ban unchecked iterator arithmeticCheck in-bounds for all allowed iterator arithmetic Check in-bounds for all subscript operations
Initialization safetyRequire all variables to be initialized (either at declaration, or before first use)—
Lifetime safetyStatically diagnose many common pointer/iterator lifetime error casesCheck not-null for all pointer dereferences
Less undefined behaviorStatically 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?”