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

Då vi redan berört det mesta som ens på något sätt kan anses relaterat till C++ (och säger det i positiv bemärkelse, detta har börjar lika tråden om elbilar fast bara det att detta är långt mer spännande ).

Kanske inte är någon nyhet alls för de som idag använder C++ som sin primära plattform, men nämner det ändå då det var ett rejält lyft för mig!

Ville testa lite saker i C++ i relation till diskussionen om DOD och såg frågan om "sökbar kod". Börjar bli ett tag sedan jag själv i huvudsak jobbande i C och C++, använde då Emacs+Cscope+(grep/etc i shell) för att gräva runt i kod. Det C++ kodande jag gjort efter det har primärt varit ihop med Unreal Engine där det finns en väldigt bra integration med Rider (Rider är helt OK, men föredrar personligen VS Code över både Rider och Visual Studio idag).

Installerar man "rekommenderat C++ stöd" i VS Code får man en OK-ish språkserver som Microsoft står bakom. Den är ju "OK-ish", men är inte alls i nivå med språkstödet VS Code har för t.ex. Rust och Go.

Sökte lite på vad som hänt med CScope, visade sig vara "typ inget sedan 2012"... Men orsaken var mer spännande, det verkar mycket beror på att det nu finns något som kan göra allt det CScope kunde göra + massor med saker utöver det:

clangd: https://marketplace.visualstudio.com/items?itemName=llvm-vs-c...

När man installerar clangd i VS Code får man frågan om det ska ersätta Microsofts intellisense, svarar man "ja" här får man långt bättre C++ stöd än vad man hade innan.

En annan trevlig sak är att Copilot-integration med VS Code gör CMake betydligt smidigare att använda. För mindre projekt är det bara att lägga in källkoden som kontext och säga åt Copilot att "write me a CMakeLists.txt that can build this project". Har fungerat förvånadsvärt bra på de fall jag testat så här långt (testa på MacOS, native ARM64 Ubuntu 24.04 och WSL2 x86_64 Ubuntu 24.04).

Tydligen var det som refererades till i "C++ är under attack enligt Bjarne Stroustrup" taget från ett intern meddelande mellan Bjarne och WG21 (namnet på C++ ISO- kommittén), ett meddelande som inte var tänkt för allmän konsumtion. Men då Bjarne ansåg att påståendet blev rätt märkligt utan kontext publicerade han meddelandet i sin helhet (det för en tid sedan, men hade inte sett det själv innan)

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p365...

Bjarnes meddelande verkar var en svar på en hel del kritik mot att "profiles" kanske inte är den lösning C++ behöver, ett exempel är detta

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p358...

Två saker man pekar på där är just bristerna med att ha det "opt-in", vilket är en punkt det "andra" C++ förslaget (https://safecpp.org/draft.html) också pekar på. Ett annat är att sättet man ska göra denna "opt-in" är på ett sätt som resulterar i något som kompilerar med dagens stora C++-kompilatorer, fast det då de helt sonika ignorerar "opt-in"-kravet.

Vidare är det faktiskt inte bara administrationen i USA som ändat sin lagstiftning på ett sätt som har relevant påverkan även för programvaruutveckling, det har även EU gjort rätt nyligen

https://single-market-economy.ec.europa.eu/single-market/good...

"PLD's rules specifically clarify that all types of software are covered by the new directive, including applications, operating systems and AI-systems."

Det som specifikt lyft fram som slagträ mot fortsatt användning av C och C++ är detta

"Under the new Product Liability Directive, a product is to be considered defective where the product does not provide the safety that a person is entitled to expect from it, or what is required under law."

Om man väljer C eller C++ utan att ha en väldigt bra förklaring till varför när någon drabbas av säkerhetsproblem som i praktiken vore omöjliga att göra i andra språk blir ovan väldigt svårt att ducka för tillverkaren.

Det här är en väldigt svår nöt att knäcka. Även om jag följer med utvecklingen av C++-standarden är det svårt att bedöma hur pass infekterad striderna är inom de som jobbar med C++-standarden. Ser rätt mycket ut att vara två, eller egentligen tre läger

1. C++ profiles, detta är det Bjarne främst pushar. Fördelarna som pekas ut är möjlighet till gradvis tillämning. Nackdelarna är att det är långt ifrån någon komplett lösning, samt opt-in för säkerhet (eng. safety) har en hel del svagheter.

2. Safe C++. Fördelarna här är att det redan finns en fungerande implementation, det är "opt-out" (likt Rust "unsafe"). Nackdelarna som pekas ut är bl.a. att det lite väl mycket känns som Rust-med-C++-syntax, varför då inte bara använda Rust?

3. I stort sett göra inget åt situationen. Initialt kändes denna rätt korkad för mig. Men ju mer jag tänker på det ju mer är detta faktiskt en fullt rimligt hållning. C och C++ kommer användas under lång tid framöver även om man väljer detta spår, men de är då likt t.ex. Cobol och Fortran, "legacy-val" som bara bör väljas därför att man behöver jobba vidare med existerande kod.

Edit: Finns ju en 4:e, även om jag inte tycker det faller inom ramen "lösning för C++"

4. Gå över till Carbon, Cppfront, etc, d.v.s. nya språk som själva är "memory safe" men som också garanterar perfekt interop med C++.

Lite relaterat: Microsoft i skottgluggen för något som tyvärr är dem rätt bekant, de lägger krokben för "konkurrenter".

Har varit lite förvånad över hur låga betyg saker som C#-extensionen i Visual Studio trots allt har. Tycker den fungerar riktigt bra efter den rätt stora uppdatering Microsoft gjorde för något år sedan. Läste ett par kommentarer och inser att väldigt många bottenbetyg kommer av extensionen inte fungerar i VSC-forkar.

Det har nu också hänt för Microsoft C++-extension

https://www.theregister.com/2025/04/24/microsoft_vs_code_subt...

Totalt sett verkar det vara 3 väldigt populära VSC-extensioner som är påverkade nu

C++: https://marketplace.visualstudio.com/items?itemName=ms-vscode...
C#: https://marketplace.visualstudio.com/items?itemName=ms-dotnet...
Python: https://marketplace.visualstudio.com/items?itemName=ms-python...

Till Microsoft försvar får man väl ändå säga att de gömmer inget här och de som använder ovan i forkar av VSC gör sig skyldiga till licensbrott

Alla ovan innehåller detta

"INSTALLATION AND USE RIGHTS. a) General. You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor Microsoft products and services (collectively, the “Visual Studio Products and Services”) to develop and test your applications. b) Third Party Components."

Men det ändrar inte "typiskt Microsoft att vifta med 'open source' flaggan för att sedan ändå ha något som hindrar konkurrenter".

I fallet C++ lyfte det det LLVM-baserade C++-plugin-alternativet ännu ett pinhål
https://marketplace.visualstudio.com/items?itemName=llvm-vs-c...

Klaus Iglbergers keynote från using std::cpp 2025 lär väl å andra sidan vara on-topic för tråden.

https://www.youtube.com/watch?v=vN0U4P4qmRY

Några inlägg som halkat offtopic har raderats. Vill man ha hjälp med sin kod är det bättre att starta en ny tråd om detta.

- MOD

Skulle säga att Klaus Iglbergers och Bjarne Stroustrup gör samma misstag. Även om deras observation är korrekt, C++ har betydligt mer problem att det borde om folk bara använde moderna finesser i språket, så tycker jag båda verkar totalt missa att ta in förstå varför så är fallet.

En av kommentarerna till videon slår huvudet på spiken

"In C++ you have to learn how to write safe code.
In Rust you have you to learn how to write unsafe code."

Ett mer annat sätt att uttrycka det är att en bra design gör det relativt svårt att använda det hela på fel sätt, en mindre bra design gör det i alla fall möjligt att göra rätt. C++ problem när det kommer till säkerhet är att man definitivt är i den andra gruppen här.

Om det bara vore ett "people problem", hur kommer det sig då att C++ står ut som väldigt mycket på denna punkt? Flera av de stora jättarna som också har stora C++-kodbaser har alla rätt liknande statistik, 60-70 % av all säkerhetsrelaterade problem kommer från buggar i C och C++ som till väldigt stor grad inte är möjliga att göra i Java, C#, Go, Rust, m.fl.

Har dessa språk mindre problematiska människor? För om det bara är ett "people problem" och inte ett tekniskt problem, varför är det då primärt ett C och C++ problem?

Man kan inte bara peka på "men det finns så mycket legacy kod". Ja, exakt! Hade det inte varit så hade lösningen varit trivial: använd något annat än C och C++!

En lösning för C och C++ är rätt värdelös om det inte också löser/kraftigt förbättrar situationen för legacy-kod. Behöver man ändå skriva om allt så är är det rationella att använda något annat. Bl.a. p.g.a. det Microsoft (Satya Nadella) nämner här: träffsäkerheten LLMs har i att jobba med kod är enligt deras erfarenhet klart sämre i C++ än C# och Python.

Sen har flera, bl.a. Sean Baxter (han bakom Safe C++ specifikationen), pekat på man rätt lätt kan formellt bevisa att vissa typer av säkerhetsgarantier kräver t.ex. begränsningar som att det maximalt får finnas ett enda sätt att referera till mutable-data. Det och flera andra saker som faktiskt krävs saknas idag i C++, även om man tar till alla former av "modern C++".

Lösningen Bjarne föreslår är i korthet att man ska kunna aktivera olika profiler, där en profil kanske fokuserar på att eliminera/minska en typ av problem som t.ex. att helt förbjuda pekararitmetik (väldigt vanlig källa till minnesbuggar, väldigt få moderna språk har ens detta även om de stödjer pekare).

Problemet med Safe-C++ är primärt att det inte tillför något på existerade kodbaser då dessa inte kommer kompilera om man aktiverar säkerhetsfunktionerna.

Att ha säkerhet som en opt-in funktion (vilket profiles i huvudsak förordar) tror jag är dömt att misslyckas. Safe-C++ är ett försök att göra säkerhet mer opt-out, men man har ju kvar problematiken då att huvudanledningen till C++ användning är att man har stora mängder legacy-kod. Safe-C++ gör egentligen ingen nytta för det.

Med profiles är tanken att man kan aktivera fler och fler "bra profiler" i mer och mer av sin kod. Men även det har problem. Är inte bara rewrites som ger nya buggar, all form av förändring av kod har en tendens att orsaka buggar. Profiles är väl en bra idé om man tror den vägen går fortare och ger mindre nya buggar än en mer sledge-hammer approach som Safe-C++.

Frågan är väl om man profiles kan nå "tillräckligt långt".

I C finns ännu en sätt att angripa problemet i form av TrapC. Likt Safe-C++ försöker TrapC skapa "Rust-lika garantier". Till skillnad från TrapC så föreslår man där att man definierar om vissa delar av språket, d.v.s. det är en bakåt-inkompatibel förändring. Fördelen över Safe-C++ är att resultatet fortfarande ser väldigt mycket ut som "vanlig C", nackdelen är att man måste kompilera om allt för att få säkerhetsgarantier + enstaka saker kommer inte längre kompilera och måste därför modifieras.

Målet är att få in en första version of "profiles" i C++26. Är inte super-påläst om detaljerna, men en sökning säger att det är 3 profiler som kan komma in i C++26 (tanken är att man framåt sedan fortsätter lägga till nya profiler)

"minimal" - är inte riktigt med på vad detta exakt gör, men beskrivningen är den ska innehålla en delmängd av C++ som är lätt att stödja i kompilatorer, OS, etc. Samtidigt som det är en delmängd av C++ som är relativt lätt att förstå. Verkar sikta lite på "vettigt första steg för de som vill lära sig C++"

"freestanding" - denna är rätt analog till Rust core, en delmängd som kan implementeras helt utan OS-stöd. Så t.ex. finns inte minnesallokering med. Detta är högst användbart för inbyggda-system, är just Rust core som gjort att Rust fått fotfäste i en rad MCUer.

"safe" - det tråden primärt handlar om. För C++26 är detta en väldigt liten delmängd, det täcker inte alls lika mycket som t.ex. Safe C++ förslaget. För C++26 handlar det om att ge en delmängd som undviker undefined behavior (UB).

För att sätta det lite i perspektiv: går väl helt OK att använda C++20 idag, C++23 är det lite mer beta-stämpel över. Så C++26 lär i praktiken vara någon man kan förlita sig på om 3-6 år från nu.

Bjarne fortsätter prata om detta, artikel på devclass
https://devclass.com/2025/05/09/interview-bjarne-stroustrup-o...

Ser ut att gå lite trögt med profiles för C++26. Mycket är redan fryst för vad som kommer accepteras in i C++26, så var hela tiden rätt ont om tid. Bjarne verkar inte helt nöjd med hur det hanterats

"He is frustrated though that there is no support for profiles in the C++ specification, nor will there be soon. “The sad thing is, the standards committee got confused and did not guarantee that this would be in C++ 26,” he tells us."

Bjarne uttrycker rätt mycket frustration kring vad han anser är en huvudorsak till väldigt många problem: "C++ skulle alls ha så här mycket problem om folk faktiskt skrev modern C++".

Gissar att Bjarne är fullt medveten om att C++ rätt mycket har delats upp i två huvudläger. De som anser att C++ redan var väldigt komplext pre C++ 11, men att det efter det blev så annorlunda och så långt mer komplext att de fortsätter att skriva C++98 då de anser det är bättre.

I någon mening får man ge dem ett par poänger. Det finns hela böcker skrivna enbart om move-semantics, det är absolut en bra finess (kritiskt om man faktiskt vill skriva modern C++ med bibehållen riktigt hög prestanda) men det är extremt komplex och enormt minfält (som GC-språk helt kan ignorera och ändå behålla prestandan).

Hello-world för C++ coroutines är även det långt mer komplext och tekniken är fylld med foot-guns som liknade funktion i moderna språk saknar (trycker i.o.f.s. async i både C# och Rust också har en del foot-guns, bara Go där det är direkt trivialt).

Blir spännande att följa UE6 också då även det har en kraftig C++-anknytning. Epics syn på bristen av bra multicore optimeringar i dagens spel är till stor del en konsekvens av att om detta görs i C++ måste alla hela tiden tänka och göra rätt kring alla problem som uppstår i sådana program (och de är många och komplexa). Det är inte realistiskt mer än på de fall som ger absolut mest utdelning.

Epic anser att enda rimliga lösningen är en där majoriteten av programmerarna kan fortsätta tänka rätt mycket som i dagen enkeltrådade program (i ett spel är redan det väldigt komplext). De enda som behöver få allt kring multicore rätt är de som utvecklar spelmotorn/kringliggande miljöer. De tror detta bara kan uppnås i kombination med ett språk specifikt utvecklat för detta, i Epics fall jobbar de på ett egen sådan språk vid namn Verse.

Får se om UE6 ger Fortnite matcher med >10k samtida spelare, något som är ett uttalat mål. Att UE4/UE5 C++ baserad motor har stora delar som i praktiken enbart körs på huvudtråden är största orsak till att dagens spel cap:ar vid strax över 100 samtida spelare per match.

Varningar och vissa specifika features kan hjälpa till med vissa saker, men det som tar en klart närmast det profiles vill uppnå idag är verktyg som clang-tidy.

Genom att kombinera flera existerande clang-tidy tester kan man komma hyfsat nära profiler som safety och freestanding, i alla fall som de initialt är tänkt att fungera.

Bjarne verkar också tycka att på kort sikt är verktyg som clang-tidy det bäst man kan ta till

"In the meantime, developers can use things like Clang-Tidy. “It has part of the checking for what I call the C++ core guidelines, which is a joint project with Red Hat, Microsoft and others,” he says."

Som nämnts flera gånger i denna tråd: som C++ är definierat idag är det i flera fall omöjligt att enbart via statisk analys hitta minnesproblem i C++-kod.

Är just detta som Safe-C++ vill råda bot på, d.v.s. ta C++ dit Rust är där man inom en safe-delmängd av språket (som måste vara majoriteten av språket för att vara användbart i praktiken) där sådana garantier är möjliga redan vid kompilering.

Vad man kan göra är bl.a. det klk förslår ovanför: dagens kompilatorer har en rad flaggor, vissa "bryter" mot C++ "zero cost abstraction" mantra men kan p.g.a. av det ge (runtime) garantier som "vanlig" C++ saknar. De är flaggor just för att en sådan kostnad är OK för vissa, men otänkbart för andra.

Rust är ett alternativ men det som @klk håller på med är att upprepa samma missförstånd gällande Rust i någon mentalgymnastik för att rättfärdiga C++ eftersom @klk verkar tro att det är en tävling mellan språk. Det är samma saker som @klk drar upp om och om igen... python, kodrader, kommentarer, method-chaining, saker som är utanför ämnet.

Om du ska utveckla ett projekt åt en kund som specificerat att projektet ska vara implementerat i ett minnessäkert språk. Skriv C++ och ta sedan diskussionen mot kunden om dom anser att C++ inte är minnessäkert. Personligen hade jag inte valt C++ utan Rust eller Go.

Om man tar en sample-size på 1 kan man "bevisa" exakt vad som helst i stort sätt var som helst... Enda potentiellt relevanta Zed tillför är att det (vad jag får fram när jag läser om projektet) visar att en sak Rust kan användas som är, likt bl.a. C och C++, högpresterande applikationer. Aldrig använt Zed, men det som lyfts fram är att det är en text-redigerare som håller väldigt hög prestanda även när fil(erna) som redigeras är gigantiska.

Vill du se exempel på idiomatisk Rust som också visar hur man dels kan skriva inom ramen för, just nu, bästa tänkbara skydd mot minnes-osäker kod kan du kika på t.ex.

https://github.com/tkaitchuck/aHash - Hashset/map som är API kompatibel med den i std:rust, fast med klart bättre prestanda

https://github.com/serde-rs/serde - väldigt bra exempel på hur "traits" kan användas väldigt ortogonalt mot andra saker ett bibliotek gör där serde "bara" tillför möjligheten att serialisera/deserialisera dina datastrukturer till JSON, YAML, CSV, Pickle, eller vad det nu må vara. Det på ett högt effektivt och minnes-säkert sätt

https://github.com/rayon-rs/rayon - min favorit då det man uppnår här är på flera sätt helt makalöst, fångar data-race compile-time. Finns få saker som är svårare att få rätt i modern programmering än just concurrency-problem.

Alla dessa tre är saker som inte är del av standardbiblioteket, men som alla är väldigt populära "crates" som alla har 100-tals miljoner nedladdningar. De är alla också utvecklare med idiomatisk Rust.

Ett uttalande som "tar betydligt längre tid att utveckla i X jämfört med Y" saknar väldigt mycket kritiskt kontext. Klart det är sant om några som primärt jobbat med X testar att göra något av liknande komplexitet i Y, innan de lärt sig Y kommer det vara svårare/långsammare.

Sen kommer "problemet" som diskutera här från observationen att C++ (och även C) står för en förkrossande stor andel av en specifik klass av buggar. Tror det tar rätt mycket längre tid att få C++ till samma kvalité på den punkten som motsvarande Rust, om det ens är praktiskt möjligt (vilket är det Bjarne et.al. vill visa att det är, för annars kommer C++ bli portat från att fler områden).

Skulle i.o.f.s. hävda att Rust har en liten särställning i raden av "språk som ska döda C++"...

Det är sant att lite väl många sagt något likt ovan. Ingen har så här långt "dödat" C++. Givet hur mycket som redan är skrivet i C++ och kommer fortsättas användas under överskådlig tid lär inget döda C++ (inget har ju lyckas döda Cobol så här långt...).

Man kan se det från en liten annan vinkel: det är rätt många områden där C++ skulle varit ett självklart val för de flesta under 90-talet som idag i praktiken helt är ersatt av Java och C#. Så för en lång rad områden "dödade" Java/C# C++, men samtidigt finns områden där Java/C# inte var en bättre lösning.

Samma med Go. Google skapade Go specifikt för att ersätta fall där de vid tidpunkten använde C++, men där de såg stora skalbarhetsproblem med C++ både p.g.a. av dess extrema komplexitet (inte positivt när man har väldigt stora och många team) samt den enorma storleken på kodbaser (kompileringstiderna var direkt horribla, mem:et är ju att första versionen av Go skrevs medan de 3 skaparna väntade på att deras C++ projekt skulle kompilera klart).

Go har sedan haft betydligt inflöde från Python, C# och Java än från C++. Nischen detta språk fyller är microservices, molntjänster och C++ har man nog primärt "ersatt" (i.e. är nog det vanligare valet idag) som språk för CLI-verktyg.

Det unika med Rust är att det nog är första språk som har ett nära 100 % överlapp med C++ i att vara topp-valet för de nischer där C++ idag fortfarande är topp-valet. Tror det är något gör att vissa inom C++-världen ser en större rivalitet mellan dessa två språk än vad man sett innan.

Men inte ens Rust lär "döda" C++. Däremot kan det ju bli en rätt snabb minskning av C++-användning om så viktiga institutioner som USA och EU mer eller mindre säger: ni får ha väldigt bra på fötterna kring varför C++ alls bör användas om organisationer vi direkt hanterar är kunden. Är väl just den delen Bjarnes "call to action" riktar sig mot.