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

https://www.theregister.com/2025/03/02/c_creator_calls_for_ac...

Interessant läsning. Bjarne är väldigt bekymrad kring C++ framtid

"I feel strongly about this. Please don’t be fooled by my relatively calm language."

Bl.a. då Microsoft CTO sagt saker som

"halt starting any new projects in C/C++ and use Rust for those scenarios where a non-[garbage collected] language is required."

Vad har du för belägg för att Microsoft har rekryteringsproblem och specifikt svårt med att hitta bra utvecklare? Bara under de senaste åren har bl a James Bottomley och Lennart Poettering gått till Microsoft.

Vilken tur! Då kan ju mail:a Bjarne och säg att han inte har något att oroa sig för

Att ett gäng personer sagts upp på CISA är inte specifikt riktat mot detta, man verkar bara ha sagt upp X % och rätt mycket gjort rent hus med de som varit där relativt kort. Något som fått kraftig kritik redan då CISA gjort flera viktiga anställningar av svårfunnen kompetens, personer som dels själva blev förvånad att de åkte och dels företag som samarbetar med CISA har uttryckt "WTF!!!".

Ingen av CISA dokument, var delvis de som startade hela detta för ett antal år sedan, är borttagna. Denna är kvar och nyligen uppdaterad
https://www.cisa.gov/resources-tools/resources/product-securi...

"The development of new product lines for use in service of critical infrastructure or NCFs in a memory-unsafe language (e.g., C or C++) where readily available alternative memory-safe languages could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety."

Problemet Bjarne lär vara fullt medveten om är att "the cat is out of the bag", diskussionen är igång och det har satt igång rörelser som inte kommer stanna bara för det kommit in en president som kör lite shotgun-surgery på ett gäng statliga verk. Även om hela CISA skulle läggas ned spelar det inte lägre någon roll. En viktig sak här är att det nu finns statistik som visar att problemen som plågar C++ (och C) är lösbara, så går inte längre att hävda "ingen har visat att det skulle fungera bättre på annat håll".

För allt fler företag har insett samma sak och har börjar implementera liknande policy.

Fast frågan är om det egentligen är ett problem? Det vi möjligen ser nu är att C++ börjat sin Cobol-bana, vilket betyder att de som vill fortsätta jobba med C++ kommer utan problem ha jobb väl förbi deras pensionsålder. Antagligen också välbetalda sådan, går ingen nöd på de som kan så ut med Cobolt och jobba med "spännande" bank-logik!

Bjarne lär vara bekymrad primärt då C++ är hans baby, han skulle kunna ha sagt "den har växt upp och får klara sig själv", men han verkar fortfarande vilja hålla den livskraftig framåt. För att uppnå det senare verkar det vara rätt mycket konsensus bland ISO C++ (och ISO C, men C lär mer än C++ kunna vara säker på att vara relevant under överskådlig framtid oavsett).

Det är inte lönt att försöka övertyga @klk vad som är sant eller inte. Personen kommer att förneka det, fortsätta trolla, slänga in slumpmässiga argument och termer med egna definitioner.

Du ser @jefff istället för att bemöta säkerhetspåståendena så nu flyttar @klk diskussionen till manuell minneshantering...

Har man inga andra språk att välja på så blir ju C++ det säkraste språket...

Det handlar inte om C++ det handlar om att du trollar

Nej, Rust kommer framförallt ta från C och C++ kakan.

Jag skulle vilja påstå att det där är nästan 100% fel.

För en del fall, speciellt i inbyggda system, så finns det få eller inga andra realistiska alternativ än C.
Det finns nog inget fall där C++ är det enda realistiska alternativet.

Bra anledningar till att välja C++ är:
a) Bakåtkompatibilitet med existerande kod
b) Det är vad utvecklarna kan, och det bedöms inte som värt det att tvinga dem att lära sig något annat språk.

Men för i princip alla andra fall finns det alternativ som fungerar minst lika bra som C++.

Att C++ skulle vara det säkraste språket lär förhoppningsvis delas av ytters få personer, för statistiken visar att det är objektvit rejält fel.

Eller säger du bara att det är en skill-issue? D.v.s. C++ är verkligen säkrast, men det drar till sig skrew-ups som om det inte finns någon morgondag och det är förklaringen till varför C++ står ut i CVEs och liknande?

Det finns en variant av C++ som skulle vara lämpligt för små inbyggda system och liknande i form av freestanding C++ sedan ISO C++20.

Till skillnad från "vanliga" C++, som benämns hosted och i praktiken kräver ett OS har en implementation av standardbiblioteket, går freestanding att köra utan OS. Rust har precis samma sak i form av std (hosted) och core (freestanding).

Givet att ingen kompilator ännu fullt ut implementerar C++20 och givet att det oavsett är ett rätt nytt tillskott till C++ lär väldigt få använda det än.

Så håller helt med, i nuläget är det främst C som är "det enda realistiska alternativet" till en rad saker. Då främst i forma av att det kanske är det enda språk som har en fungerande kompilator till lite mer obskyra CPU-arkitekturer.

Flexibilitet ger inte säkerhet. Oftast gör det inte ens säkerhet enklare att uppnå.
Stor flexibilitet ger stort utrymme för misstag, och därmed för säkerhetsproblem.

För att få bra och säker kod så vill man helst att det skall vara lätt att göra rätt, och svårt att göra fel. Det är inte precis något som beskriver C++.

Unity DOTS har de relevanta/unika delarna i C#. Med hjälp av ECS får man där ett system som är dels något lättare att jobba med än de flesta tidigare varianter, samtidigt som dess arkitektur gör att minne utnyttjas på ett väldigt optimalt sätt.

Får se om det blir populärt. För DOTS har varit lovande länge, men det blev egentligen stabilt nog för en 1.0 release relativt nyligen och det kommer ta en del tid att anpassa existerande bibliotek/ramverk till denna modeller.

Rent generellt är just spel ett bra exempel på ett område som C++ helt dominerade för 10-20 år sedan, men som i allt större utsträckning nu går till andra språk. Multicore och C++ går att göra bra, men det är många gånger hjärndött komplicerat utan att ge några prestandafördelar över alternativen.

Sen är spel lite speciella i att majoriteten av flaskhalsarna ligger idag i shaders. Dessa är exakt lika snabba oavsett om man tragglar i C++, assembler, Python eller C#.

Och vet man hur det ska göras har vi massor med exempel idag som är säkra och väldigt effektiva. Inom vissa områden, t.ex. I/O-tunga jobb som högpresterande webservers, är inte ens längre C++ snabbast utan det kan ofta göras ännu snabbare i bl.a. Go.

På denna punkt är Go unikt, det är en av få språk som inte går via libc utan man går direkt mot systemanropen för att kunna göra saker på sätt som överhuvudtaget inte är möjliga i C/C++, del av I/O-prestandan kommer från detta designval.

Så idag har vi fall där C och C++ faktiskt inte ens är snabbaste, även om det är teoretiskt möjligt att skriva en egen runtime i C/C++ som fungerar på samma sätt. Fast då är man inne på helt icke-standardsaker som med designen i C eller C++ kommer vara extremt error-prone (har testat i C, coola benchmarks men mardröm att programmera...).

Det här är äpplen och päron igen... Ja, övning ger färdighet men det är orelevant i sammanhanget.
C och C++ program innehåller fler minnesfel än Rustprogram, av den enkla anledningen att det är betydligt lättare att göra fel.

"Kärnan" är maskinkod när man faktiskt kör programmet, i.e. det är rätt irrelevant att det finns vissa delar som är skrivna i X, Y eller Z. Det relevanta är att domänen "skriva spel" allt mer går mot andra språk, där C# är det som ökar mest här.

Och specifika poängen här är: DOTS/ECS ger spelprogrammeraren en C# miljö som är väsentligt bättre på att utnyttja flera CPU-kärnor samt SIMD. Detta får man rent tekniskt genom att göra en rad optimeringar relaterade till access-patterns mot minne, men det trevliga är att det görs på ett sätt som är hyfsat automatiskt. Det man måste "offra" är att logiken skrivs på ett rätt annorlunda sätt mot "normala" mono-behavior klasser.

Bara som ett lackmustest av fokus här: det gick faktiskt inte att skriva ett multitrådat program i standard C eller C++ innan 2011, något som var möjligt i Java sedan första release 1996 och första release av C# 2002.

Sedan är det helt klart så att en GC har en viss overhead, men om man jobbar med multitrådade program på multi-core plattform finns ett gäng fördelar med GC rent effektivitetsmässigt. Ett populärt sätt i C, t.ex. i Linux-kärnan, är att skapa tillräckligt mycket av en GC för att få lock-free algoritmer som sequence-locks, korrekta.

Nu verkar du nöjd att spela strut-fotboll och göra allt med det enda verktyg du har (C++). Fungerar det för dig: great!

Men ibland vill man gräva en grop istället för att slå i spikar, då kan en spade (Go) vara bättre än en hammare (C++). Är flaskhalsen "compute" är det inte speciellt svårt att få ett C++ program att bli snabbare än motsvarande Go program.

Är däremot flaskhalsen I/O har Go fundamentala fördelar på väldigt låg nivå (bl.a. i hur man binder in standardbiblioteket mot OS-systemanrop) som man på C/C++ nivå inte kan riktigt matcha med mindre än att göra bypass på libc/crt vilket då diskvalificerar användning av standardbiblioteket och alla bibliotek som ligger ovanpå det (typ alla förutom ett par väldigt nischade saker för embedded-system).

Att skriva en webbapplikation i Go som hanterar 1k-10k samtida användare är något många studenter skulle kunna fixa med rätt grundläggande kunskap i språket. Göra det i C++ är långt mer komplicerat och inte alls säkert att det ens blir snabbare. Även här ligger orsaken i att Go har på väldigt låg nivå en scheduler som är specialanpassad / optimerad för just den här typen av applikationer.

Det är inga problem, det är även idiomatisk, Go att bara dra igång en "gorutin" per session. Det använder relativt lite stack-utrymme, det kommer schemaläggas på "en lämplig mängd OS-trådar" etc. Startar man en OS-tråd per session, vilket den enkla/naiva lösningen i C++, kommer systemet blir brutalt långsamt.

Sättet C/C++ modelererar en tråd är kopierad från POSIX som tyvärr designades när normalfallet var CPUer med 1 CPU-kärna och man därför inte riktigt insåg att man blandade ihop koncept som borde hanteras separat: "tasks", "OS-trådar" och "fysiska CPU-trådar".

Go har "rätt" abstraktion här för att man bara rakt av ska kunna designa sina programm enligt detta
https://en.wikipedia.org/wiki/Communicating_sequential_proces...