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

Så är det inte alls. För att ta ett annat perspektiv vilket jag tror många utvecklare inom C++ också funderar över så handlar det generellt om denna nya ide om C++ och minnessäkerhet. Varför just amerikanska underrättelsetjänster går ut med det.
Det är som att förstöra möjligheter att utveckla bra mjukvara med ekosystemet och mängden kod som driver det mesta.

Om programmerare inte lär sig hantera minne kommer de heller inte klara och göra en hel massa som är viktigt för att få till en hel hög med olika lösningar

Jag håller verkligen inte med, tvärtom så när det är krav på säkerhet är det C++ som skall väljas men självklart behöver de som skriver koden behärska språket.
C++ i rätt händer är det säkraste som finns

Från början var C++ ett högnivå språk. Men det är från grunden och fortfarande ett lågnivåspråk i stil med C (jämfört med C# och andra nya varianter av språk)

I c++ hanterar du _alltid_ minnet i grunden själv. Alltid. Det finns hjälpmedel som kan hjälpa dig på vägen, men all officiell dokumentation som finns förtydligar hela tiden hur viktigt det är att ha stenkoll på vad som händer under huven när du använder dessa hjälpmedel. Nu har vi kommit till en punkt att alla dessa hjälpmedel snarare stjälper dig, eftersom att mängden information du måste hålla koll på för att göra allt rätt och by the book är så stor att det blir orimligt att kunna göra det, och det blir kontraproduktivt istället.

Bra C++ kodare skapar sina egna verktyg och hjälpmedel, och då sitter all denna information i ryggmärgen från början.

Vid detta laget bör man absolut använda ex. c# om man vill ha dessa hjälpmedel gratis, för då bryr man sig troligtvis inte om fördelarna med att göra saker by the book.

Kanske är jag mest inne på att man ska använda rätt verktyg för rätt jobb. I kombination med trenden att försöka göra en hammare (C++) till en såg (C#). Du kan vässa den där hammaren hur mycket du vill, men i slutändan kommer den fungera dåligt både som hammare och som såg.

Ett exempel från verkligheten:

På mitt dagsjobb så hanterar vi stora mängder data. Denna data måste samlas in snabbt, processerar snabbt (med en mängd tunga filter/annan signalprocessering), sparas snabbt, läsas snabbt, och rasteriseras snabbt.

När jag kom dit så hade vi ett par olika mjukvaror, som alla presterar riktigt dåligt. Koden var skriven i diverse högnivå språk, med skräckexempel som länkade listor av doubles för rådata som allokerades hit och dit överallt. I dessa mjukvaror så finns det fullt av laddningstider, buffringstider när man läser/rasteriserar data, och många vänt-tider på förprocessering. På high-end desktop PC.

Jag påbörjade en ny ersättningsmjukvara, där jag använder Dart/Flutter för UI, som funkar bra för sin sak, men sen har jag implementerat allt tungt lyftande i ett C bibliotek istället. Resultatet? Allting som den gamla mjukvaran gjorde på en highend PC, med långa väntetider, buffringstider och förprocesseringstider på flera minuter, körs nu istället helt i realtid på en midrange Android tablet, med 20-120 FPS (beroende på vad man gör och hur mycket processering som är inräknat).

Detta är en prestanda skillnad på flera storleksordningar.

Detta uppnådde jag genom att väldigt noggrant göra allting by the book, i C, där jag noggrant kontrollerar minnesaccess, allokeringar, hur cache fetchas, multitrådning osv osv.

Rätt verktyg för rätt arbete helt enkelt, med fenomenala resultat. Detta kanske är ett skräckexempel, men jag ser den här trenden överallt; lata programmerare som inte kunde bry sig mindre om att göra saker korrekt, och förlitar sig alldeles för mycket på högnivå hjälpmedel utan att bry sig om att förstå hur dom fungerar i grunden. Sen väljer dom ibland C++ för att "då blir det snabbare".

-- Och nu för att knyta an till topic: --

Vill du ha enkla hjälpmedel, inte behöva bry dig så mycket, och så vidare, så finns det INGEN anledning att använda C++ alls. Det blir så himla mycket bökigare. Använd för bövelen C# istället.

Och ska du använda C++, så snälla använd det för vad det faktiskt är bra på (och i mitt tycke vad det är designat för); Lågnivå programmering!!

När C++ kommitten nu frenetiskt arbetar för att försöka göra C++ till ett såntdär "enkelt högnivå språk", så blir det att dom sabbar språket istället. Och samtidigt uppmuntrar en destruktiv trend som spridit sig brett i industrin, och som förstör den; Lathet.

C++ kommitten borde skärpa till sig och arbeta för vad C++ faktiskt är istället, och ge oss bättre lågnivå verktyg (istället för värdelösa högnivå-abstraktioner som ger noll värde), mindre ambiguitet (istället för mer), simplifiera saker istället för att lägga till komplexitet (det är programmerarens uppgift).

Sen om du ändå vill plåga dig själv och använda C++ för lat programmering så be my guest, men du gör ingen en tjänst (och verkligen inte dig själv).

Bara en kommentar angående Concepts, den vart mycket lyckad. Har precis börjat använda concepts och förenklar samt möjliggör en hel del saker som kanske endast 3 personer (eventuellt några till men många är det inte) i världen behärskade med templates tidigare.

Vad som är svårt beror på vem du frågar och var dennes kunskap ligger.

Men om du pratar med programmerare som kan hårdvara (vilket man kan tycka de flesta programmerare borde kunna). Så skulle jag nog säga att
std::unique_ptr, std::span, std::array, std::variant och möjligen en del i algorithm.h som är tveksamt till att användas. Där tror jag många väljer att lösa det själva.

- Move-semantik, Lambda-uttryck, constexpr, consteval är bättre kompilatorer. Kompilatorn är ett viktigt verktyg för C++ utvecklare och att man kan nyttja detta verktyg bättre gynnar många.
- Ser man till stl där det gör nytta för många så de objekt som gör att utvecklare kan skriva plattformsoberoende kod, där är nyttan stor. Exempelvis är några delar i Boost väldigt användbara just på grund av att koden fungerar på olika operativsystem och hårdvara.

Personligen så gör jag skillnad på programmerare och kodare. Att bli kodare är inte så svårt, lära sig något språk och vad språket erbjuder i hjälp. Så är det med C++ också, man kan lära sig språket och dra nytta av STL och ibland lyckas få ihop något utan att vara programmerare.

För mig är en programmerare en person som förstår sig på hur datorer fungerar och kan skriva program. För dem är ett språk endast ett av alla verktyg som behövs för att skriva applikationer.

Det här behöver jag protestera mot. De absolut bästa C++ programmerarna är de som först lärt sig C och sedan gått över.
Går man rakt på C++ och försöker använda STL till allt utan att lära sig vad som händer ytan (vilket många låter bli), då förstår de inte och den koden dessa programmerare producerar är inte rolig med få undantag.

Satt nyligen i kod där det exempelvis fanns en std::tuple som hade över 30 objekt. Den används som någon form av lista utan att vara en lista med "smart" kompilator-teknik för att hämta respektive objekt. Självklart har det från början inte tänkt varit en sådan lösning men man kan trassla in sig något otroligt med cool C++ och sedan är det en mardröm att ta sig ur.

De som först lär sig C lär sig också hårdvara och förstår vad som sker även när de kodar C++ och risken för missbruk av stl och templates är inte alls lika stor. De väljer i princip alltid en enklare lösning vilket ofta fungerar utmärkt även om det kan bli något mer kod jämfört med "smart" C++ och de trasslar inte in sig lika lätt.

Förutom att inte missbruka C++ så de som lär sig jobba med minnet och kan ibland göra lösningar som förenklar och klarar saker där annat producerar mängder med kod. Att jobba direkt med minne är också ett mycket kraftfullt verktyg.

Här är en json parser från ett företag som ofta sponsrar C++ event, "think-cell". Ett tyskt företag och de är kända för att ha duktiga C++ programmerare.
Koden i länken är alltså bra C++, de är väldigt duktiga på att använda nytt i språket C++ så detta är alltså inget skräckexempel.
https://github.com/think-cell/think-cell-library/blob/main/tc...

Trots att detta är bra C++ hade jag i 10 fall av 10 valt en mer C anpassad parser med inslag av vettig funktionalitet i C++ för den typen av kod blir mycket enklare att läsa, debugga och hantera.

Störst problem med "C++ nördar" om jag kan uttrycka mig så är att de blir förälskade i språket. De förstår inte att ett programmerings språk endast är ett verktyg för att producera maskinkod och där är det mycket att tänka på för att få till en fungerande lösning. Exempelvis skriva kod som är lättläst, lätt att debugga, dokumenterad och så vidare

Här diskuteras "Contracts". Det är på gång i C++ och utan att själv gått djupare i det så vad jag förstår är det macrot "assert" men att det byggs in i språket och får mer funktionalitet.

Med detta sagt så glöms det ofta av hur mycket funktionalitet C/C++ har för att generera säker kod.
Exempelvis makrot "assert", ser jag någon kritisera säkerhet, man får se kod från personen och den inte har kod som granskar. Då vet man att vederbörande pratar i nattmössan.
assert är mycket viktigt, hade jag fått välja mellan att använda tester eller assert så är det ett lätt val. assert tar så mycket mer och utvecklare ser direkt när de gör fel. Krångligare kod så kan säkert ~30% av koden endast vara för att kontrollera.

Projektverktyg som CMake är också en skänk från ovan, CMake får ofta kritik för att det är för svårt/konstigt och det stämmer till viss del. Gissar att CMake byggdes för att hantera stora projekt och sedan konverterat till något som många använder. Nu har det blivit default.
CMake är dock mycket enklare idag jämfört med några år sedan. Det går till och med att debugga CMake kod i visual studio, går kanske i andra verktyg med.
Här får också ofta C++ kritik för att det är för komplicerat med att hantera projekt. De som kritiserar förstår inte att säkerhet kräver att man vet vad för typ av kod som används och hur. Att det är lätt att plocka in nya komponenter är inget som är bra för säkerhet.
CMake är heller inte språkberoende för C++ vilket gör att att man kan göra mycket runt om för projekt. Att CMake är så flexibelt är en styrka, inte en svaghet. De som kritiserar och att använder argumentet det är för svårt, tror jag inte förstår det.

Tipsar om den här blogposten, mycket bra text som går igenom dispyten inom linux där de prövar på att ha med RUST.

Texten går igenom varför det kan vara så svårt för programmerare med olika bakgrund och/eller kunskap att diskutera. Samt vad som fungerar och vad som inte gör det.
Rust doesn’t belong in the Linux kernel; it’s all about ideology

Om det är en styrka eller inte kanske går att tvista om men det är absolut en mycket viktig faktor.
Startas ett större projekt idag så väger den biten mycket tungt. Jag hade aldrig valt att använda de alternativ som finns för C/C++ om det är för ett större projekt.
Känner till några företag som börjat nosa på RUST, har för mig att bl.a. Volvo använder det men jag tror inte det flyter speciellt bra med tanke på deras förseningar.

Det här tror jag faktiskt stämmer mycket mer på andra språk jämfört med C eller C++. Min uppfattning om de som använder C eller C++ är att de vet exakt varför de måste använda det, det finns egentligen inte något alternativ. Man vet redan innan att det är svårare och det är svårt att hitta kompetens men måste ha en pragmatisk vinkel och därför behöver ta det ändå.
Har jobbat en del med C# utvecklare, fantastiskt svårt att diskutera teknik med många där. Där stämmer det enligt mig mycket bättre med "Jag gör som jag alltid har gjort.".

Här håller jag inte med och det är av två orsaker, alltså om man fått för sig att skriva ett nytt OS.
Rust har väl fortfarande endast en kompilator (LLVM), Zig tror jag har två (LLVM och någon egen). C++ har 3 som dominerar och två bra till (alla stödjer mer eller mindre det senaste i språket vilket inte är lite). C har väl över 100 kompilatorer.

Men för mig som ännu inte testat Rust var artikeln jag postade helt avgörande för jag kände inte till att så simpla saker som att göra en länkad lista är en utmaning i Rust.

Citerar artikeln (avsnittet Dead End):
I mentioned that initially I thought Rust was a good idea, in fact, in the previous article I wrote about it I still gave it the benefit of the doubt, however, it all changed when I tried to write a simple linked list, which turned out to be impossible.

Jag förstår precis vad Felipe Contreras (han som skrivit posten) menar. Att behärska minneshantering och få lov att göra vad man vill är ett fantastiskt verktyg. C programmerare kan detta. De vet hur mycket de kan göra genom att kontrollera minnet.
Detta är den största styrkan med C och de som inte lärt sig hantera minnet har svårt att förstå hur starkt detta är.

Det går aldrig att vinna över en kodare som vet hur man jobbar med minnet jämfört med andra kodare som skriver "säker" kod. Framförallt går det att skriva återanvändbara lösningar som helt krossar andra lösningar i effektivitet. Men har man aldrig lärt sig detta är det som hokus pokus, de förstår inte.

Andra citatet
When I discuss with Rust advocates and mention the fact that you can’t write a simple linked list like linux does (intrusive doubly circular linked list), they say two things 1) “yes you can” (untrue), and 2) “you shouldn’t want that”. Typical “it’s not happening and it’s a good thing that it is” responses.

The moment somebody tells me “you shouldn’t want that”, I stop using their software. Period.

Den reaktion Felipe Contreras beskriver här är helt logisk för C och C++ programmerare. Skulle någon använda argumentet "you shouldn’t want that" mot mig sett till hur vilka lösningar som går att göra, då har vederbörande dragit ner byxorna på sig själv. Jag skulle inte ens fortsätta argumentera för det är så dumt.

En duktig C programmerare som kan hantera minnet kommer springa cirklar kring utvecklare som försöker koda samma sak utan att direkt manipulera minnet.

Absolut, efter att han läst in på C vs Rust i Linux så är det någon slutsats man kan dra så är det att inte blanda. C nördar kan inte diskutera med Rust nördar. Två olika världar.

Här tror jag faktiskt på motsatsen. LLM verktyg är bäst för de som "vet vad de håller på med" om beskrivningen tillåts. Utvecklare som inte helt är med på vad som genereras kommer enligt mig att hamna i skiten ganska omedelbart. De vet inte när det är dags att bromsa eller de måste göra långsiktigt. Jag tror att det är vanligare att C programmerare vet vad de gör och LLM verktyg plockar också upp mönster snabbt. Bra struktur har bättre nytta av verktyget.

LLM kan självklart skriva en hel massa python eller för att inte ta webben, där kan man fråga nästan var som helst men det blir mycket duplicerad kod och det gäller att kunna rätta och/eller refaktorera.

Som jag tolkar det nu så fungerar LLM bättre för språk som C eller C++ jämfört med enklare språk när det gäller projekt som kan skala. Precis sett ett projekt skrivet i python som helt gick över styr, 4 utvecklare som satt ett halvår och fick slänga och göra om. De har lärt sig mycket, bl.a. att man måste skriva kod som går att underhålla.

Menar du att det inte finns färdiga bibliotek i C++, måste man alltid börja på 0
Finns massor att välja på om man inte vill skriva logiken själv.

Givetvis skall man inte välja C++ om man saknar kompetensen, välj det utvecklarna behärskar.

Varför skall de skriva om? Det är inte mycket som kan konkurrera med C idag

Är du säker på det, skall inte Linux gå och kompilera på en hel hög med olika processorer och därför måste köra C

Hade heller inte valt C++ för operativsystem. Med så många deltagare och att släppa lös C++ programmerare blir det snabbt extremt svårt att tolka koden. C++ kräver extrem disciplin.

Vad han gjorde var att välja den enklaste han kunde hitta och det var tydligen problem. Jag vet inte hur andra gör i Rust men sökte lite och det såg inte ut som att det var lätt. Och läs vad han skriver angående hur lätt det är i C++ att lägga på heapen eller på stacken. Det samt att styra vad som sätts (har för mig att Rust alltid sätter pekare till null).

Det är möjligt men det finns användning för en hel hög med andra strukturer i alla fall. Och de kan vara betydligt mer invecklade än en länkad lista.

Som sagt, jag vet inte vad som passar i deras miljö men jag tror de har koll på vad som fungerar bäst.

Har inte Go en GC? Allt med GC går bort omedelbart för mig. Så slött, men självklart så behövs inte prestanda eller att man kan slösa på minne så spelar det mindre roll

Efter att följt en del diskussion och granskat mer hur de resonerar så kan jag säga att C och Rust inte kan jobba ihop. De är för olika och jag tror faktiskt att Rust har sett sina glansdagar eller snart ser det. Därmed inte sagt att språket inte kommer användas för jag tror många småprojekt kommer köras med Rust. Men den attityden de har och hur språket fungerar gör att de aldrig kommer klara att hantera större projekt.

Jag tror IT jättar håller på att tänka om eller i vart fall måste de förändra sin affärsmodell. Det har framförallt att göra med AI men även att det är nytt styre i USA. De har kunnat leva gott på att IT varit ett oligopol. Saker som DEI håller på att läggas ner.

Den nya administrationen i USA verkar vara inriktad på marknadslösningar så gissningsvis blir det ändringar. Flera IT jättar har redan börjat ändra om.

C++ har alltid varit på “dekis” ändå så om man skulle ta ett genomsnitt av all maskinkod som körs på datorer är förmodligen över 90% kompilerad C/C++ kod. Det läggs mycket mankraft på resterande 10% och det har och göra med att där sker konvertering från data anpassad för datorer till människor.

C++ är inte ett språk för alla, språket är inte gjort för att vara lätt. C och C++ är optimerade verktyg för att klara av och bygga exakt det utvecklare vill bygga och göra det så bra som möjligt.

Allt sådant här tar tid att lära sig, många projekt som kraschar eftersom så få utvecklare kan bygga större system. En frustration många C++ programmerare ofta känner och därför bara struntar i att ta diskussionen.
"nya" utvecklare som precis löst sina först grejer och plötsligt tror de kan skriva vad som helst, hur många har inte varit med om det? De måste sätta sig i skiten innan de fattar att det tar lång tid att bli duktig, att lära sig ett eller några språk är den enkla biten.
De allra flesta lär sig aldrig och kanske heller inte behöver för majoriteten av all utveckling handlar om att underhålla system.

Flera stora företag i Sverige har riktigt dyra och stora projekt som kraschat på grund av ledningen inte förstått hur man skriver system.
Känner själv till flera och några som är på väg.
Men för att ta ett äldre system så man inte avslöjar företagshemligheter

Sök på EHPT, stort företag samägt mellan Ericsson och HP, 3000 anställda och gjorde system för växelsystem till mobiler.
I slutet på 1990 talet vart java väldigt poppis, allt skulle bli objektorienterat. EHPT beslöt att skriva sitt nya system i java istället för C som befintligt system var gjort i. Mycket pengar investerades och man höll på att utveckla i knappt 3 år om jag minns rätt. Några utvecklare ( alla falll en, en vän till mig ) som satt där som konsult förstod efter några månader för han kom in senare, att projektet höll på att haverera. Prestanda var inte i närheten av vad de måste klara av och java är segt som sirap.
Han försökte ta upp det med ledning men de vägrade lyssna. Många chefer med hög lön som inte kan utveckla, låg mycket prestige i beslut. De kan inte backa. Företaget gick i konkurs och anställda hade turen att de kunde gå över till Ericsson.

Känner till flera liknande även om EHPT kanske är det största i Sverige som konkade. Volvo Car har mega problem, de har köpt in nya företag för det är för tungt att byta kunskap när så många är rädda om sina jobb. Deras smala lycka är att andra bilföretag har samma problem.
Ericsson är hyffsat duktiga idag, de hade flera kraschade projekt i början på 2000 talet där de lärde sig mycket. Men det är tufft att hitta kompetens.

Personligen tror jag att om det skulle komma något bättre än C/C++ hade en majoritet bytt ganska omedelbart om de inte sitter i kod som behöver underhållas. Erfarna programmerare där är pragmatiska. De kan också snabbt se om ett språk är värt att titta på. Nästan alla "nyare" språk har byggt in hinder som de marknadsför som features, alltså bra grejer. Där reagerar många erfarna precis tvärtom, det blir stora hinder.