C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

Feature freeze är passerat för C++26, det möte som ska fast ställa de sista detaljerna hålls i Bulgarien/Sofia i juni.

Det som fortfarande är lite frågetecken kring är exakt vad kring "profiles" som kommer att vara med i C++26. Verkar som det blir väldigt lite, det som Bjarne var upprörd över för en tid sedan.

Annars är det som @klk skriver ovan, de stora sakerna är contracts och reflection.

Lyssande precis på avsnittet om libstdc++ hos CppCast: https://cppcast.com/libstdcpp/
Det belyser ett annat problem C++ har m.a.p. att agera kring minnessäkerhet.

Varje sig libstdc++ (GCC, används som förval på Linux även om man kör Clang) eller libc++ (Clang/LLVM, används som förval på MacOS även om man kör GCC) har idag en fullständig implementation av något efter C++17(!). Målet för libstdc++ är att ha fullt C++20 stöd innan C++26 spikas i slutet av 2026.

Och tyvärr är det mer än smådetaljer. Skrev ett par rätt enkla testprogram för Coroutines (C++20), std::execution (C++17/20) och använda en sådan enkel sak som std::print (C++23). Stötte på problem i alla dessa exempel med att lyckas bygga/köra ett omdifierat program som använder dessa saker på Linux (testade GCC/Clang och libstd++/libc++) och MacOS (testade Clang/GCC med libc++).

Detta problem har lyfts av många. Det tar väldigt många år från att en C++ standard idag spikas till att den faktiskt går att räkna med i programvara som måste vara portabel.

Rust, Go, C# och TS har alla "fördelen" av att nya standarder rätt mycket stöds dag #1 vid release. En orsak där är att man stoppar in saker i standarden som man redan implementerat och testat i den enda toolchain man har (vilket i sig kan vara ett problem).

Java fyllde precis 30 år. Där kommer en ny version varje år och en "LTS" var 3:e år likt som för ISO C++. Frågan är varför Java-gänget verkar kunna hålla flertalet toolchains rätt nära standarden trots samma kadens som ISO C++? Likt .NET har ju Java ett enormt standardbibliotek som fortsätter växa. Likt C++ läggs inte supermycket till i språket, men likt C++ händer ändå en del fortfarande.

C++ standarden styrs av ISO. Men det är inte så himla mycket byråkrati runt framtagandet av standarden. Det som tar tid är snarare att få folk att komma överens.

De olika implementationerna av C++ och dess bibliotek har ISO däremot ingenting alls att göra med. Vilket kanske är en del av problemet.
De som jobbar med C++ kompilatorerna och biblioteken verkar inte ha någon större brådska eller intresse av att faktiskt förverkliga alla finesser och nyheter som folket i standardiseringskommittén hittat på, plus att en del av nyheterna kan visa sig lite svårare än förväntat att implementera.

På ett sätt var det bättre förr för C och C+. I början så experimenterade kompilatortillverkarna hej vilt med olika utökningar och tillägg till språken, varpå standardiseringsfolket tog med ett urval av till standarden. På det sättet fanns mycket av nyheterna i standarden redan implementerat i verkligheten.
Men sen, när det fanns en etablerad standard, så blev både kompilatorutvecklare och användare negativt inställda till icke-standardiserade utökningar, och så hamnade vi i dagens situation.

Kan väl hålla med om att affärsintresse ligger bakom det men av felanledningar. Säkerhet kommer aldrig att generera nya intäktsströmmar som nya features/tjänster/produkter utan möjligen enbart spara pengar så företag väljer att hellre satsa på garanterad vinst mot möjliga lågriskförluster.

Nu när det kommer/kommit striktare lagkrav som i större utsträckning håller företagen ansvariga så har vågskålen balanserats om något och det är inte samma låga risker som tidigare.

Jag hade hellre sett att medmänsklighet och större respekt för personlig säkerhet/integritet hade styrt detta än rena kapitalistiska incitament. Känns inte som att något utvecklas med målet att bli den bästa möjliga produkten längre utan allt ska kramas ur för att maximera vinsterna.