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

Utan att ha tittat på vad Bjarne sade har jag en känsla av att ambitionsnivån är lite längre. Det handlar nog snarare om att man numera kan klara ganska mycket utan att själv behöva tänka så mycket på minneshantering och pekare.

Gillar inte C++, fick avsmak för språket redan då jag gick kursen för 20+ år sedan p.g.a. en del syntax-konstruktioner som var helt bakvända i min värld. Det blev inte bättre när jag under flera år jobbade med support på språket och buggarna haglade omkring mig. Kompilatorn hade inte sina bästa år just då..

Bjarne anför att C++ är ett bra språk, bara man "använder rätt funktioner". Dessa funktioner läggs till efter hand och språket växer över tid och blir svåröverskådligt för nytillkomna. Men visst kan man se det positivt som att C++ blir ett "Heltäckande språk" med tiden, YMMW.

När man ska utveckla något, så är första frågan vad vill man åstadkomma?
För väldigt många projekt så är det olika mål, ett av målen är att det ska vara billigt att utveckla och även underhålla. Där nyexaminerade personer ska kunna hoppa in i projektet direkt utan risk att de gör dumheter.
Där minnesläckage kan vara ett fel som är svårt att upptäcka och åtgärda.

C++ språket har sina fördelar som prestanda men ofta så är de andra sakerna viktigare... Jag förvånar ofta över min iPad med Apple M4 hur otroligt segt vissa applikationer ändå är på denna snabba krets, men det är inte precis prestanda som har prioriteras i dessa.

C++ språket utvecklas, säkerligen kommer det bli mer minnesäkert. Nu var det länge sedan jag kodade C++, men jag ville minnas att om man bara struntade i prestandan och hur koden såg ut, så gick de mesta problem lösa utan använda pekare och göra det bra minnessäkert.

Ok men då är det inte C++ längre.
Liksom ska alla standard bibliotek skrivas om till att vara utan pekare... Igen baggage och andra språk.

Sedan håller jag med att det borde inte vara svårt att skapa ett minnessäkert (och presterande språk)
Skriver själv "minnessäkert" genom att låta alla objekt ligga på interface och låta ARC göra sitt, borde inte vara svårt att kräva det i kompilatorn (och att objekt instanseras vid första referensen)

Jag jobbar med C++ som primärt arbetsspråk sedan snart 20 år. Det har utvecklats massor och man kan skriva väldigt bra och ganska säker kod med det idag. Men det kräver hög disciplin och ganska hög kunskap av den som skriver koden. Dessutom har det som så mycket annat utvecklats genom att man lagt till saker men inte orkat rensat bort särskilt mycket vilket gör att man kan göra samma saker på många olika sätt vilket enligt mig inte är önskvärt i ett programmeringsspråk. Jag älskar C++, särskilt när det är skrivet på ett sätt som jag gillar, eller i alla fall hyfsat vettigt och enligt "Keep it simple" principen. Men jag skulle inte säga att det har framtiden för sig.

Håller på och försöker lära mig Rust för det har väldigt många fördelar gentemot C++ för framtiden och som du skriver TS så önskar stora spelare som MS och USA att man ska gå mot säkrare språk som Rust.

Dock ska det sägas att t.ex. Cobol och liknande språk har ännu mindre framtiden för sig men arbetsmarknaden är bra för de få som är bra på det för det finns så mycket legacy system men väldigt få nya utvecklare vill lära sig det. Det kommer att finnas enorma mängder C++ legacy i decennier framöver så om du inte planerar att jobba efter 2100 så kan du nog försörja dig hela vägen till pensionen på C++ kunskap...

Känns som att det kommer ta ett tag innan det finns standarder för säker mjukvaruutveckling med Rust, så de branscher som utvecklar säkerhetskritiskmjukvara lär inte använda Rust på ett tag. Räcker inte med att det finns språk som är bättre om man inte kan sälja sin produkt med det.

“Simply writing any new code in Rust reduces the number of new vulnerabilities and over time can lead to a reduction in the number of outstanding vulnerabilities,”

https://www.securityweek.com/google-pushes-rust-in-legacy-fir...

Tyvärr är det oerhört komplicerat, givet den grad av frihet c++ erbjuder, att avgöra vad som faktiskt orsakar problem. Bakåtkompatibilitet är ju också oerhört viktigt i c++, och man vill ju inte ha falsklarm för kod som faktiskt är korrekt även om den råkar använda ”osäkra” konstruktioner.

Det skrivs ju mycket, men jag vet inte om detta är något som har blivit särskilt mycket akutare inom c++-världen. Det är ju knappast några nyheter.

Ofta behöver man väl knappt offra prestanda heller? Numera behöver det till exempel inte vara ett problem att returnera vektorer från funktioner.

Problemet med att rensa är ju att gammal kod skulle sluta fungera, och det är inte ett alternativ i c++.

Bjarne i all ära, har väldigt stor respekt för vad han bidragit med kring programutveckling. Ändå har han fel här.

Punkt #1: bara titta på statistiken. Över 50 % av alla buggar som görs i C++ är sådana som de "säkra" språket alla skulle hindra. Det Bjarne i praktiken säger här är: det går ju att göra rätt, så gör rätt... Modern C++ gör det lättare att göra rätt, men absolut inte omöjligt att göra fel.

Punkt #2: även om någon framtida version av C++ skulle lösa alla problemen med minnessäkerhet måste man ställa sig frågan "varför används ens C++ idag?". Svaret är att så mycket existerande kod är redan skriven i C och C++, C++ har lysande kompatibilitet med detta.

Om kravet är att all kod ska skrivas om i "modern och säker C++" kan man ju lika gärna skriva om det i ett annat språk. För finns definitivt kvar en rad vårtor i C++.

Vill säga att C++ ligger mig varmt om hjärtat. Även om jag hade lyckats skriva lite saker i BASIC och assembler tidigare, var det med C++ jag verkligen lärde mig programmera. Har undervisat i C++, att vara vikarie på gymnasium var väldigt bra extraknäck när man var student. Och varit med och utvecklat C++11/14 standardbiblioteket för VxWorks.

Men är ändå bara glad att jag till nästan 100 % helt har kunna lämna detta språk bakom mig

Man skulle absolut gradvis kunna deprecatea och sedan förbjuda konstruktioner i C++. Det skulle kräva viss successiv omarbetning av existerande kodbaser men det gör vi på mitt jobb idag genom att successivt öka graden av "treat warning as error" och omarbeta gammal kod så att det bygger och kör med allt striktare regler. Jag tror inte att vi är särskilt unika.

Att det är svårt politiskt är en sak men det skulle vara klart praktiskt genomförbart att säga att t.ex. C++27 kompilatorer och framåt ska förbjuda nakna pekare till förmån för referenser eller smartpekare och låta versioner upp till dess varna för sådana konstruktioner. Kodbaser som inte vill uppdatera får stanna på c++25 eller whatever.

Det är klart att man kan, men det känns väl helt främmande för hur c++ fungerar idag? Jag är skeptisk till att det finns något större intresse av att gå åt det hållet med hela språket.

Måste och måste. Det förutsätter ju att den nyaste versionen av C++ är bättre än de äldre, vilket inte är så där alldeles självklart.
Och sen beror det på vad alternativen är. Om ett alternativ är att skriva i något annat språk än C++, så är det nog oftast en större förbättring.

Snarare så att många projekt har en stor mängd kod skriven enligt äldre standard.
Att skriva om den koden enligt nyare riktlinjer skulle kräva mer jobb och tid än det antagligen är värt. Så man får leva med gammal kod i projektet.

Och sen finns det ju fall där man är tvungen att hålla sig till en äldre språkstandard för att det inte finns någon uppdaterad kompilator för den plattformen man jobbar mot.

I ingendera fallet behöver projektet eller de som jobbar med det vara oseriösa eller okunniga.

int foo(std::vector<int> xs)
{
    auto index = compute_index(...);
    return xs[index]; // out-of-bounds-access
}

int add(int a, int b)
{
    return a + b; // undefined behavior if overflows
}

Där är två exempel där det första är i grunden överlägset vanligaste problemet i C och C++ program.

Det andra är inte helt sällan orsaken till att man hamnar i det första, även om det mer handlar om att någon beräkning blev negativa eller slog runt på ett sätt som man inte tänkt sig. Själva UB-delen är i sig ett mindre problem i praktiken då resultatet kommer bli "rätt" vid overflow med alla populära kompilatorer på alla populära CPU-mikroarkitekturer.

Rust har inget av problemen. Det andra då beteendet är väldefinerat där. Mer viktig går det inte att göra första buggen med mindre än att använda sig av "unsafe" context.

Den huvudsakliga skillnaden mellan C++ och egentligen alla andra moderna programspråk är att C++ är "unsafe by default" medan alla andra är "safe by default".

Vare sig C eller C++ kan i praktiken ändra just denna default. Gör man det kommer de inte längre vara bakåtkompatibla och då är de poänglösa.

Huvudanledningen att använda C och C++ var väldigt länge att de gav stora möjligheter att skriva väldigt snabb kod. Här har det egentligen bara en direkt konkurrent, Rust. Men Rust är verkligen lika snabbt, faktiskt snabbare i vissa lägen p.g.a. vettigare aliasing hantering.

Sen är extremprestanda kritiskt där det behövs. Men finns väldigt många fall där det i praktiken inte spelar någon roll i själva applikationen. Att Python av alla språk börjar bli populärt i mikrokontrollers visar detta. De kritiska delarna som hanterar interrupt och liknande är i C eller C++, men väldigt många IoT applikationer går utmärkt att köra med Micropython för de behöver bara göra en rätt enkel sak i oändlighet.

Personligen fördrar jag dock lång mer TinyGo eller Rust över Micropython.

Artikeln handlar om android och inte säkerhetskritiskmjukvara, det jag pratar om är alltså metodiken vid utvecklingen som måste finnas på plats för det programmeringsspråk man väljer för produkter som klassas som säkerhetskritiska. Det handlar alltså om utveckling av mjukvara för tex vapen, flygplan, bilar, infrastruktur, etc.

Det är ett ganska extremt exempel men om man vill gå mot minnessäkring eller något annat modernare paradigm (t.ex. const som default och ett keyword för mutable som Rust har är ett annat exempel) så skulle man kunna göra det. Det skulle förmodligen krävas en hel del, men jag menar bara att det skulle vara tekniskt möjligt att modernisera C++ även om det förmodligen inte finns intresse bland tillräckligt många inblandade för att driva det ditåt. Enklare att bara gå över till ett nytt språk. Väljer man något som Rust kan man ju fortsätta köra sin äldre kod som binärkompatibla moduler så länge det behövs också.

Du menar alltså säkerhet som i "safety", inte "secure". Lite lurigt med svenska här då vår namngivning inte särskiljer på "skydda enheten från omvärlden" (secure) och "skydda omvärlden från enheten" (safety).

Avundas definitivt inte de som behöver få till så att en C++ kompilator går att använda ihop med DO-178C (aviation) eller ISO 26262 (automotive).

Har själv bara jobbat att certifiera mot DO-178C level A med ISO-C89. Även om statistiken visar att det faktiskt går att göra "säker" C kod skulle jag inte hävda att detta bevisar att C är något man bör använda i normalfallet för att bygga "säker" kod.

Prislappen för att nå denna typ av säkerhet är astronomisk. Uppskattningen jag blev berättad var >$100 per färdigcertifierad C-rad.

Positiva: det är tekniskt möjligt.
Negativa: det är bara realistiskt om man verkligen måste p.g.a. prislapp. Och har aldrig varit med om något så "tråkigt" att jobba med som utvecklare som detta, enda ljuspunkten är "har i alla fall gjort det en gång i livet"..

Även om man inte når nivån som krävs i dessa standarder med "moderna programmeringsspråk" så är deras primära värde i att de lägger lägstanivån långt över lägstanivån hos C eller C++. Och för majoriteten av all programvara är detta långt viktigare.

Precis, kanske borde refererat till den engelska motsvarigheten.

AUTOSAR (bilindustrin) verkar även arbeta på en metodik för att använda just Rust, men som med alla dessa standarder så tar de tid att framställa och produkterna som implementerar de tar lång tid att utveckla. Beslutet på språk görs även i början av projekten och ofta vill man återanvända befintlig kodbas som redan uppfyller de hårda kraven, det som tar tid är trots allt inte att skriva koden utan alla dokument, tester, analyser och kravlänkning.