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

Vem ska lyssna på vem? Du får det att låta som det är kyrkor och inte programmeringsspråk. Du beklagar dig tidigare i tråden över Rust-evangelister men ingen har försökt påtvinga dig något annat språk medans du snackar illa om GC-språk, Python och hävdar att X enbart går att lösa på effektiva sätt i C++... när ska du inse att du är evangelisten som du tycker så illa om?

Jag har kodat C i 13 år för Linux och nu hobbykodar jag i Rust, så det borde vara exempel nog på att det troligen kommer lösa sig framöver

Well, just det markerade kan vara ett problem i C, C++ och Rust då man kan få "slut på RAM" trots att det egentligen finns massor med ledigt RAM som effektivt av fragmentering.

De flesta moderna GC språk har inte det problemet då de kan kompaktera sin heap och därmed helt eliminera (extern) fragmentering.

Nej, vad jag säger är att en fördel med GC är att den har liknande fördelar som en arena-allokator när det kommer till att allokera väldigt stora mängder buffertar per tidsenhet. Kostnaden för allokering är långt mindre än normal heap-allokering i språk som C++.

Nu bör man försöka undvika att göra det, vilket ofta (men inte alltid) är realistiskt genomförbart. Fördelen med GC-språk är att om det är svårt att undvika presterar de fortfarande helt OK, medan C++ går rejält i diket.

Ett par av föredelarna är

* Kostnande för att allokera är väldigt låg (lägre än att allokera från heap i C, C++ och Rust)
* Extern framentering är ett icke-problem, något man explicit måste tänka på i C, C++ och Rust för program som förväntas köra under mycket lång tid utan omstart
* ABA-problem är rätt mycket ett totalt icke-problem i multitrådade program med GC, samtidigt som den problematiken helt klart är en försvårande omständighet för att skriva lock/wait-free algoritmer i C, C++ och Rust

Men det betyder inte att GC är en hammare som går att använda precis överallt. Nackdelen med GC är att den inte är deterministisk, vilket gör den olämplig för realtids-applikationer (i praktiken oanvändbar när man har hårda realtidskrav). När man skriver spel (mjuk realtid) med C# så måste man se till att skapa ingen/lite "garbage" om man vill ha stabil FPS.

Realtid är dock inte att likställa med hög prestanda, hård realtid betyder bara att det går att garanterar ett "worst-case".

Den genomsnittlige C/C++ utvecklaren? Nej.

Såg du videon?
Kan du förstå att rendering/spelutveckling är en bra tillämpning för arena-allokering?
Du inser också att mycket programmering inte har samma behov som rendering/spelutveckling och kanske därför blir sämre om du använder en arena-allokator?

Nu är jag ingen expert på GC, men jag tror att svaret är att det gör du inte. Det behöver du inte göra.
Om du kontrollerar när minne släpps så missar du hela poängen med en GC.

... och inget du sagt har med rubriken att göra ...

Rubriken har att göra med huruvida C++ är minnessäkert och det du skrev handlade om att olika programmerings communities har olika behov och behöver lyssna på varandra. Jag är övertygad om att kumbaya inte kommer göra C++ minnessäkert ...

Go

runtime.GC()           // Run garbage collection
debug.FreeOSMemory()   // Release unused memory to the OS

C#

GC.Collect();                  // Run garbage collection
GC.WaitForPendingFinalizers(); // Run "destructors"
GC.Collect();                  // Run garbage collection for any additional free objects after running finalizers
GC.TrimExcess();               // Release unused memory to the OS

Hur vet du hur stora block C++ allokerar från vare sig heap och än mer OS? Det vet du inte, närmaste man kan komma är att allokera ett stort block och hantera minnet själv, vilket också går i de flesta GC-språk.

För de som hellre vill se en video än att läsa, här är YouTubern "ThePrimeTime" take on Bjarnes senaste utspel kring "attacken mot C++"

Det är inte alls så självklart att man kan tvinga fram en GC. Utanför debugging är det en operation man nästan aldrig behöver eller ens bör göra då det sällan är positivt för prestanda.

Vill man kasta ut saker på blocknivå får man göra en custom-memory allocator, vilket är möjligt i stort sett alla GC-språk. Specifikt är det möjligt i C# (har använt mig just av arena-allokator där, är högst lämpligt om man t.ex. vill göra vettiga partikelsystem i C#) och definitivt möjligt i Go (förutom denna shit-storm kring C++ framtid p.g.a. dess säkerhetsbrister pågår också en sådan runt varför Microsoft valde Go när man optimerade prestanda i Typescript kompilatorn, det i stället för C#, Rust eller C++. En väldigt viktig orsak är "Go is the lowest level language that exist, still using a GC").

Men om man tar ett kliv in i detta millennium och därmed att multicore är normen så finns väldigt ofta begränsningar på minnesallokering som inte spelar någon direkt roll för enkeltrådade fall. Det är enklare/effektivare att hantera lock/wait-free algoritmer om man sätter begränsningen att minne är typ-stabilt, d.v.s. efter allokering måste en viss minnesadress representera samma typ fram till dessa att minnes frias igen. Med den begränsningen lär nog i princip alla programspråk kunna köra med en custom-memory allocator om behov uppstår.

C har en särställning bland språk i att vara den ABI-specifikation som i princip alla andra språk bygger sin FFI.

Sedan har C, C++, Rust och Zig (möjligen något till jag missat) en särställning i att alla ha manuell minneshantering vilket är ett krav om man bygger applikationer med hårda realtidskrav. Inför man manuell minneshantering i språk som normalt har GC kan även dessa uppfylla detta krav, finns (eller har i alla fall funnits, vet inte om det aktiv underhålls längre) varianter av Java med dessa egenskaper.

Utöver det är det ytterst få saker som kräver C, C++, Rust etc. Om man definierar "prestanda" som "hur snabbt man kan lösa ett givet compute-bounded problem" är rätt arkitektur och rätt val av bibliotek typiskt långt viktigare än val av språk. Se på AI/ML där prestanda är super "trots" att Python är standarden att jobba i.

När man rör sig mot multicore-optimeringar är det snarare en fördel att välja de mer högpresterande GC-språken. Vilket kanske inte egentligen är så förvånande givet att C designades i slutet av 60-talet och C++ skapades i slutet av 70-talet, långt innan multicore var normen (båda dessa språk var ju väldigt sena med att ens ha standardiserat stöd för trådar, 2011 i båda fallen).

Absolut! Dock högst intressant att läsa reaktionerna givet att denna "influencer" ändå har >700k följare. Och det som tas upp där är helt on-topic för denna tråd.

Hela "C++ framtid" handlar i nuläget primärt om vilken väg man ska ta

* Bjarne anser rätt mycket att problemet redan är löst. Det som saknas är bättre verktyg, han trycker på "Profiles" som i praktiken är ett sätt att göra så att specifika delar av språket (de delar som anses vara "problematiska") inte längre kompilerar (säkerhet by opt-out). Man kan då gradvis skriva om existerande kod i "modern" stil, ett exempel som lyfts fram är att C-style arrayer och pekar-aritmetik ska bannas, istället ska man använda C++11 och senare tekniker.

* Safe-C++ lägret tycker det fortfarande finns en rad brister och vill rätt mycket kopiera de delar från Rust som visat sig vara väldigt värdefulla för att i stort sätt helt lösa de vanligaste orsakerna till säkerhetsproblem i C och C++.

* TrapC (som jag personligen tror är klart bästa vägen framåt) är OK med ett par "breaking-changes" till språket, med fördelen att slutresultatet löser problemen samtidigt som själva stilen på hur man kodar bevaras nästan helt. C++ saknar tyvärr ett motsvarande förslag (än så länge).

* Ett sista läger är väl Carbon och Cpp2. De är rätt mycket för C++ vad Typescript är för Javascript och t.ex. Kotlin är för Java. Man anser att det inte är realistiskt att fixa de underliggande problemen med språket, samtidigt som man också inser att det redan finns så mycket legacy-kod som man behöver ha 100 % stöd för. Ett sätt att hantera detta är att skapa ett nytt språk som inte har vårtorna, men som "bara" transpile:as till det underliggande språket (vilket är kanske viktigast för just C++ då det saknar en standardiserad ABI).

* Eller möjligen är sista lägret de som hävdar: "this is fine!". Vet inte om det finns något relevant antal här...

Jag känner nog ingen som hatar C. C++ å andra sidan upplever jag som en vattendelare men det är sällan pga av dess funktionalitet, prestanda eller liknande utan att C++ precis som Java och Rust har en tröskel som är jobbig att ta sig över och sedan tror jag att många har andra personliga preferenser gällande syntax, tooling osv.

Detta är än en gång ett konstigt och något nedlåtande påstående. Min gissning är att om du bedriver en diskussion på samma sätt i verkligheten som du gjort i denna tråden så kommer du har svårt med att få gehör oavsett vilket språk som motparten kodar i. Det låter som du redan har förutfattade meningar och placerat motparten i ett fack så fort du har fått reda på deras daily driver och sedan är det jäkligt svårt för motparten att kämpa emot dina fördomar.

Jag lovar att det fanns och finns utvecklare som skriver både VB och C++, vilket fack placerar du dom i?

Är inte det en del i utvecklingen? Det dyker upp nya tekniker som löser vardagliga fall för vissa utvecklare och därför blir dom exalterade och vill testa det, är inte det OK?

Samma poäng som innan... du placerar dom i ett fack och försvårar därför diskussionen från start.

Det är för att TS specifikt ville veta om detta och inte de mest stabila språken. Isf har väl Klarna en tjänst som är skriven i Erlang som snurrat i 11 år(denna siffran är några år gammal) och i Erlang har man filosofin "låt det krascha" för att det inte spelar någon roll eftersom man har mekanismer för att automatiskt starta om applikationer och hot-swap:a för att patch:a utan down-time.

Varför tror du att det finns olika programmeringsspråk?

Ännu ett ofattbart korkat påstående... Du låter nedlåtande pga att dom programmerar ett annat språk och inte för att dom inte kan sina saker och nu säger du "man måste träna för att bli bra" det är ju ett helt annat resonemang.

Du kanske skulle träna lite så att du ens kan komma nära dina egna ideal?

Lärde mig C++ 1991, undervisade i C++-programmering i slutet av 90-talet samt har bl.a. utvecklat standardbibliotek för C++11/14 till RTOS. Så har många goda minnen av språket och anser att det framförallt under 90-talet var toppvalet för rätt mycket "det mesta".

Erfarenheterna är självklart olika. En av de första uppdrag jag hade när jag började jobba var i ett projekt där egentligen allt var utvecklat i just VB. Var då själv ansvarig för lågnivå-delarna och var då inga större problem att övertyga övriga om att "även om detta teoretisk skulle kunna utvecklas i VB är C++ det bättre valet här".

Har däremot mött en hel del som "avskyr C++". Det har med förkrossande majoritet varit C-programmerare.

Och har tyvärr 1:a-handserfarenhet som visar att motståndet mot C++ ibland inte är helt ogrundat. Har pushat igenom användning av C++ i en organisation som primärt använde C (och för högre nivå saker Python), det kändes efter ett tag som ett misstag för har nog aldrig sett värre kod än vad vissa (rätt kompetenta C-programmerare) lyckades få ihop i C++...

Och Java var en stor förbättring inom många, men långt ifrån alla, områden över C++. Har också 1:a-handserfarenhet av detta. Pushade tidigt för att skriva om den (B2B-säkerhetsplattform) företaget hade och som initialt var skriven i C++ i Java.

Initial reaktionen var "höhö, bara noobs som skriver i något annat än C++". Lät bli att säga allt för mycket när det ett par månader senare bestämdes: "typ alla våra kunder har börjat använda Java, så vi ska skriva om hela vår SDK i Java"...

Fast det är ingen åsikt eller gissning att just minnesproblem står ut ett stort problem i C och C++ kodbaser. Samt att det är specifikt ett problem just i dessa språk då liknande system skrivna i "minnesäkra språk" i långt mindre utsträckning har den typen av problem.

Så har historiskt haft en väldigt positiv syn på C++ och saknade det under åren jag primärt jobbade med C (fast var helt med på att C++ inte var ett alternativ där då det handle om kernel-kod).

Men har svårt att se någon relevant anledning att idag välja C++ i ett greenfield- eller ens brownfield-projekt. Tiderna förändras, med den tekniken och med den hur man bäst utnyttjar tekniken programmeringsmässigt. Tror det kommer göra att C++ är vår tids Cobol oavsett vad man gör, men just då det är Cobol kommer alla vi i denna tråd vara begravna innan det inte kommer gå att ha en programmeringskarriär som C++-programmerare för den som vill (är själv väldigt glad att kunna lämnat det bakom mig).

Kan ha fel på det sista, och följer utvecklingen av C och C++ av egenintresse.