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

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

Det där var väl lite att ta i? Saker kan bli fel i alla språk, även i Rust. Den stora skillnaden är att Rust inte låter dig läsa garbage utanför din vector och köra vidare som om inget hade hänt.

Exakt och det är det viktigaste här. För just att skriva med en galen offset är orsak primär orsak till väldigt många problem.

Ingen språk kommer hindra dig att göra logiska fel, men är väldigt stor skillnad på en kontrollerad krasch och "ingen vet vad som kommer hända, men statistiken är inte nådig i hur ofta det som händer inte är något bra".

Samma med att inte ha UB, går fortfarande att göra fel på en rad olika sätt även om det är väldefinierat. Men det blir i alla fall samma fel oavsett underliggande CPU/OS-plattform.

Sen får vi se om Rust blir riktigt populärt. De kanske tagit det lite väl långt, rätt stor tröskel innan man känner att man kan göra det man vill utan att fightas med borrow-checker... Det + att jag personligen värderar superkorta koda-compile-köra cykler gör att jag föredrar Go över Rust, även fast Go inte alls plockar lika många fel compile-time. Det har "tillräckligt" hög lägstanivå för mig (gillade att koda C och Go känns mer som ett modernt C, medan Rust kanske mer är ett modernt C++).

OK? Så om du tar exemplen jag gav ovan, hur kompilerar jag det så OoB of overflow upptäcks? Genuint nyfiken på i vilka lägen man löst detta!

För overflow-check även i release för Rust skickar man med "-Coverflow-checks=true" till kompilator så blir det panic vid sådana fel (annars är det definierat till 2-kompliments overflow). OoB check går inte att stänga av.

Sen är nog en av de mest värdefulla egenskaperna hos Rust att deras modell gör att race-buggar i multitrådade program inte kompilerar. Denna klass av buggar kan vara extremt svåra att felsöka (helgrind och LLVM ThreadSanitizer kan hitta vissa fall, men långt ifrån alla).

Huruvida det går att single-step-debugga beror en rad faktorer. Det går utmärkt att single-step-debugga Arduino program på många MCU:er. Arm-baserade plattformar har nästan alltid en SWD-port, har specifikt testat detta på RPi Pico + deras SWD-prob ihop med Platform IO. Fungerar också på CH32V20x baserade RISC-V MCUer (där räcker det med USB-kabel, dev-korten har integrerad SWD).

Ännu lättare med TinyGo då den plattformen har stöd för att integrera en gdbstub, vilket gör det möjligt att debugga bara man har någon form av "rimlig" kommunikation (UART, TCP/IP etc).

Micropython har vad jag vet ännu inget debugger-stöd. Men där har man istället möjlighet att köra en REPL på MCU, något som kan vara otroligt användbart för att testa sig fram.

Har inte benchmarkat, men av någon anledning pekar Compiler Explorer på att v.at(i) i C++ är dyrare jämfört med v[i] i Rust (i alla fall något fler instruktioner), vilket kanske har en bra förklaring.

Men ja, det löser problemet i nya program som använder "at", hjälper föga i de 99,9 % av den kod som finns i alla bibliotek man lär använda om man 2024 väljer att köra C++.

Språk föds ju titt som tätt, gemensamt för dem alla är if/for/while, d.v.s. grunderna för den typ av programmering vi gör idag (enkeltrådat). Är det bara tycke och smak som gör att språken är så olika att det blir svårt att göra rätt? C++ hade ju den stora fördelen att C-kod i stort sett accepterades. Så varför väljer man att låta t.ex. Python enbart förlita sig på indentering när samma skrivsätt i C/C++ sedan länge anses vara en felkälla. Rekommendationen där är ju att alltid använda klammerparenteser.

Nu finns det ju översättsprogram mellan olika språk, men sådan kod måste ju verifieras noggrant då man introducerar en ny felkälla (översättaren). Vore inte tanken att i så stora och möjliga drag ändå försöka få nya språk att så nära som möjligt likna ett tidigare språk. Jag ser att hela branschen skulle tjäna på detta för att minska trösklarna att hoppa mellan olika projekt skrivna i olika språk. Om man ser till relationen mellan C och C++, så varför inte kunna ha ett program som antingen kompileras som Rust eller C++? Vi programmerare beskriver ju bara vad som skall göras, kompilatorn får ta hand om hur det skall göras.

Jag har inte fått med alla tankar här, men i stora drag kanske ni förstår åt vilket håll jag tittar.

Vad är din fråga här egentligen?

Jag vet inte riktigt vilket (av dina egna) inlägg du hänvisar till, men är det kod som du har behövt använda i en produkt/tjänst, där du har varit tvungen att byta från C++ till Rust för att kunna slutföra projektet?

Eller är det en akademisk fråga utan egentlig relevans i verkligheten?

Om du fick bestämma så skulle ju alla köra Rust på Apple Silicon, och det är en typ av ideologisk inställning som bara en akademiker kan ha, nån som lär istället för att göra.

Och för oss som är lite äldre så har vi ju sett mängder av såna buzz words komma och gå.
Du kan absolut ha rätt, det kan vara så att alla ska och kommer köra Rust på Apple Silicon, men det kan också vara så att det är den här tidens Betamax eller PowerPC.

"Man" väljer inte det. Den person som skapade Python tyckte att indentering var ett bra sätt att ange vilket "djup" kodraderna är på.
De som skapade C tyckte inte det, utan där krävs klamrar för att definiera kodblock.
Delvis har det att göra med teknikens framsteg - på den tiden C skapades så var Teletype-terminaler fortfarande vanligt förekommande, men när Python skapades så var ganska avancerade texteditorer vanliga som kan varna om indenteringen ser konstig ut.

Men klammrar vs indentering är egentligen en petitess och en smaksak.
Det är andra saker på lägre nivå som är viktigare när det gäller.

Det finns inget egenvärde i att ha språk som ligger så nära tidigare språk som möjligt. Visst, det är dumt att ändra saker bara för att ändra, men att lära sig nya språk och byta mellan olika språk är inte särskilt svårt.

Språk som C# och Java är ju syntax-mässigt rätt lika C just för att programmerare är vana vid det, och för att det inte fanns något behov av att ändra på den punkten, även om de språken på andra sätt skiljer sig mycket från C.

Grundstrukturen för hur man skriver program, och hur man tänker när man skriver program, kan skilja sig markant mellan olika språk.
Jämför till exempel program skrivna i ML eller något annat funktionellt språk med ett program skrivet i Pascal eller annat procedur-orienterat språk.
Du kommer knappast att hitta många for-loopar eller while-loopar i ett ML-program, däremot mängder med rekursiva funktionsanrop, för det är det naturliga sättet att implementera iterationer där.

Du har helt rätt, om jag fick beställa skulle rätt många saker fungera betydligt mer optimalt ur ett rent tekniskt perspektiv. Nu är jag med råge tillräcklig pragmatiker för att inse att det aldrig kommer vara sant mer än i den lilla sfär jag faktiskt kan kontrollera (och lovar dig, den fungera från ett tekniskt perspektiv väldigt bra).

Kör Windows just nu 11 och C# som primärmiljö, det är med 100 % ett pragmatiskt val. Hade jag valt fritt hade det varit MacOS och Go... Positiva är att det ändå går att köra på en ARM64 Mac, trots overhead med Parallels så kompilerar projektet ändå lika snabbt på en M3 Max laptop som på en 14900k

Exemplen i fråga är dessa (de enda exempel jag gett i denna tråd BTW)

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
}

Undran jag gjorde är kring det @icucode skrev ovan

Kompilatorer och länkare har utvecklats väldigt mycket de senaste åren för C++. Med rätt flaggor kan man upptäcka många minnesbuggar idag inklusive out-of-bounds access och overflow.

Vilka flaggor handlar det om? Nämnde då också specifikt att Rust faktiskt har en flagga som styr exakt hur overflow ska hanteras i det senare fallet (man kan välja mellan definierad 2-kompliment overflow eller panic).

En superpositiv effekt av AI-trenden tror jag kommer bli att det framåt kommer bli långt enklare att välja språk efter behov. Orsaken är att LLMs börjar bli skrämmande bra att ta en kodbas och skriva om den i ett annat språk. Till skillnad från transpiling där man får en oläsling sörja som output får man från LLMs något som är minst lika bra som många programmerare kan producera.

När det kommer till uppdateringsfrekvens är likheterna mellan C++ och Rust långt större än olikheterna.

Kompilator: tittar man specifikt på Clang för C++ så verkar en ny punkt-release släppas ungefär en gång i månaden, vilket även gäller för Rust. Väldigt lite att förvånas över här då båda använder samma projekt i botten: LLVM.

Major-versioner: C++ släpper en ny version var 3:e år, senaste är C++24. Rust närmaste motsvarighet är "Editions", dessa har så här långt släppts 2015, 2018, 2021 och är en planerad under 2024. Så vart 3:e år.

Stora skillnaden är att C++ behåller bakåtkompatiblitet i varje ny version. Genidraget med Editions är att man byggde in stödet för det i hela toolchain så är explicit möjligt att kombinera bibliotek skrivna med t.ex. Ed 2015 medan applikationen är Ed 2021. Varje ny "Edition" kan göra förändringar som är bakåtinkompatibla, d.v.s. man har ett tekniskt fungerade sätt att rätta mindre bra beslut utan att paja existerande kod!

Sen får vi se om tekniken kring editions håller i längden, blir ändå ett visst merjobb att säkerställa korrekt funktion av äldre editions. Här har andra moderna språk, som Go, valt en mer traditionell approach: alla nya versioner måste fortsätta stödja alla äldre versioner från 1.0 och framåt. Det man i huvudsak förlorar där är hur snabbt man kan röra sig framåt, det tar ganska lång tid i Go (vilket är gäller för C och C++) från idé till att något hamnar i standard.

Jag bara antar att du är ironisk, för du låter som en lågstadie-elev som säger ”om alla bara var som jag så skulle vi ha fred på jorden och allt skulle fungera mycket bättre..” i någon slags självinsikts Dunning Kruger.

Men om vi bara antar att det är korrekt, så om alla skulle vara som du så skulle vi också ha utveckling på din nivå, därav min fråga om produkter/tjänster du har utvecklat.

Jag menar, det är såklart inga problem att få ett hobbyprojekt man utvecklar hemma att fungera perfekt, och ju mindre det är desto lättare är det.

Så att din miljö fungerar perfekt är bara relevant i perspektivet vad som är resultatet av den miljön.

Exempel på vad jag implementerat inkluderar: TCP/IP stacken för Perseverance Mars Rover och ASMLs litografimaskiner (det är i C), kontrollsystem som används i safety critical system i flyg/bilar (primärt C, men lite i C++ och Rust), kontrollsystem för BMS, fastighetsautomation och liknande (primärt Go med lite C).

Men ja, var självklart delvis ironisk eftersom man aldrig kontrollerar alla delar.

Tror jag och @heretic16 har liknande hobbyintressen. Där håller jag rätt mycket på med microkontrollers och enklare system för att managera dessa. Skriver nästan idag uteslutande det senare i Go idag medan MCUerna är en blandning av C++ (Arduino), MicroPython och TinyGo.

Fast ser inte riktigt hur det hör hit...

Vilket jag också gör. Är amatör i kretsdesign och elektronik, så gör bara den delen för hobbyprojekt.

Vet tillräckligt för att lycka få ihop automation-/övervaknings-systemet jag har i sommarhuset. Är kapabel att använda logikanalysator och oscilloskop för denna nivå... I jobbet gör andra göra kretsdesign, men är med i val av komponenter ibland.

Sen får du nog omvärdera vad som är "leksaker". Sådant som t.ex. RaspberryPi, Raspberry Pi Pico, Arduino och även Micropython används idag i "riktiga" industriprojekt. Gissar att det finns spelare som ser en sinande inkomst då dessa system ersätter ofta rätt dyra proprietära system, och de blir ersatta inte bara p.g.a. pris utan inte helt sällan är även tekniskt bättre lämpade.

Nja, språk som Elm och Haskell har inte de konstruktionerna alls. De har beräkningsmässigt likvärdiga konstruktioner, men konceptuellt helt annorlunda.

Jag vill nog påstå att det inte främst är olikheten mellan språk som gör det svårt att göra rätt, utan snarare egenheterna och svårigheterna inom varje enskilt språk.

Känns som att du vänder på argumentet här. I C/C++ har ju indentering ingen semantisk betydelse, varför klamrar rekommenderas så att man inte råkar skriva kod som om indentering hade betydelse:

if (true)
  a++;
  b++; // Ser ut som en del av if-satsen, men är ej det.

I Python har indentering betydelse, så koden betyder per automatik det den ser ut att betyda.

Det är väldigt stor skillnad mellan hur en programmerare kan uttrycka sig i olika språk.

Går tyvärr inte, enligt din egen definition nedan är STM32MP157 att betrakta som "leksak". Det är en produkt vars tillgänglighet bara garanteras i 10 år. Mer seriöst: i framtiden kanske, är i startup-fas av ett nytt företag och det tar all tillgänglig tid!!!

Sen har STMs "garantier" kring tillgänglighet visat sig vara vatten värda i fall där produkten i fråga inte blivit en storsäljare. Samma verkar gälla andra drakar som Renesas och Microchip.

Här verkar Intel ha lite mer verklighetsnära garantier, de lovar (och har historiskt hållit detta) 7 års tillgänglighet för produkter i deras "embedded"-vertikal. Sen är det en annan klass än MCUer (man försökte ge sig på MCUer med x86 i form av Quark, vet inte hur man tänkte där med det misslyckades naturligtvis rejält vilket var uppenbart för de som testat plattformen, men ändå lite synd att jag lyckades tappa bort mitt Quark dev-board...).

Det finns helt klart kretsar som varit i produktion betydligt längre än lovat, men det är liten tröst om man var tillräckligt naiv att tro att dessa "garantier" kring tillgänglighet faktiskt går att lita på till 100 %. I slutändan måste produkterna vara vettig business, att hålla produkter med väldigt låga volymer tillgängliga bara för man "lovat" det fallet inte inom detta.

Nu låter du rätt mycket som frugan. Hon nämnde någon gång att "X har ju motsvarande funktion och X kan inget om datorer, hur kan det vara svårt?". Här var inte huvudpoängen att få till funktionen, det var att göra allt själv från komponenter, givare, motstånd, etc + skriva alla programvara själv.

Om nu 30 år är kritiskt för dig, vilket tror du sannolikast kommer kunna uppdateras/förändras/lagas om 30 år

* Propretära system från t.ex. STM
* Raspberry Pi Pico / Arduino UNO / Arduino R4 som alla använder öppen källkod och där också kretsdesignen är öppen

STM har 4 nivåer för tillgänglighet, 7, 10, 15 och 20 år. Sista gruppen verkar man övergett, inget nytt har adderats dit sedan 2014. 15 års gruppen innehåller MCUer för bilindustrin (==dyra) och icke MCU-kretsar.

UNO börjar bli lite "stale", men där sitter ändå en krets som funnits på marknaden i >20 år. Pico använder Cortex M0 (egen SoC-design) och R4 använder Cortex M4 (från Renasas), två väldigt vanliga Arm CPUer även i STM-kretsar.

Väljer man någon av de senare har man rätt många val kring programvara. Här finns stöd Arduino (C++, eller mer C-with-classes i praktiken), Micropython och TinyGo. RPi Pico går också att använda med mer avancerade system som FreeRTOS.

Sen har RPi Pico en riktigt "killer feature", framförallt ihop med Micropython (men går även att använda med t.ex. C++) i form av dess programmable I/O co-processor. Det gör det både mycket enkelt och framförallt effektiv att skriva cykel-perfekt I/O-kod, något som är möjligt på t.ex. STM ihop med C, C++ eller Rust men är betydligt mer komplicerat utan att på något sätt vara bättre eller snabbare.

Svagheten hos RPi Pico är främst total avsaknad av analog-input/output, men går ju att fixa med en extra krets.

Kul ändå att se att även STM skådat ljuset. Framåt verkar de allt mer pusha sin VS Code extension över Eclipse baserade STM32CubeIDE. Man säger själv detta

Markerade säger i praktiken: vi kommer inte säg från officiellt håll att STM32CubeIDE nått EoL, men dra era egna slutsaser när vi flyttat resurserna till VS Code.

Varför gör man det? Finns flera orsaker, men en är att man ser hur "leksaksalternativen" på flera sätt blivit trevligare att jobba professionellt med jämfört med dyra (sett ur interna resurser) propretära IDEer.

Ser det som positivt. Under åren jag jobbade med VxWorks hade vi internet debatten kring "varför plöjer vi ner resurser i en Eclipse-baserad IDE som 'alla' verkar hata?". Internt fick vi ibland klagomål på: hur kan X/Y/Z strular så mycket i Eclipse, har ingen märkt det. Där var sanningen att internt använde vi Emacs, VIM och senare VS Code etc för att gå jobbet gjort...

Sedan ett par år tillbaka är just VS Code + plugin vägen framåt där. VS Code är en så mycket bättre editor än Eclipse, framförallt för C, C++ och Rust (de språk som officiellt stöd på VxWorks, var drivande att få in Rust). Till Eclipse försvar kan man ändå säga: det är en OK IDE för Java, sämre än IntelliJ men OK.

Kan du vara specifk? Vad exakt är det som inte är bra?
Tar man Arduino har det bl.a. börjar användas i vissa PLC:er, stora fördelen är att man kan bygga produkter till lägre pris.

Visst kan man fsck-up med Micropython, men "rätt" sätt att hantera minne där är precis som i C eller C++ för en MCU: allokera allt minne vid start och släpp aldrig referensen -> inget problem. Så till skillnad från "vanlig" Python programmering krävs förståelse för minneshantering i väldigt begränsade miiljöer även om man kör Micropython.

Varför Volvo, eller antagligen någon biltillverkare, kör RPi Pico lär ha minst två förklaring:
1. de använder väldigt ofta CAN, finns många MCUer med integrerad CAN men RPi Pico är inte en av dem (finns inte heller i vanliga RPi, dock har Arduino R4 CAN samt även Orange Pi 5, använder med fördel OPi5+Go+CAN i "industriprojekt").
2. allt som hittar in i en bil man kan köpa är rejält gammal, RPi Pico är rimligen allt för ny att finnas i någon existerande bilmodell

Sen tillbaka till tråd-topic: här är lite "modern" C++ (initializer_list kom i C++11 och string_view i C++17) kod-haveri. Buggarna med string_view är tydligen tyvärr inte alls ovanliga i "verkligheten". De kompilerar helt utan varning och tenderar ge rätt svar i debug-byggen och ibland även i release-byggen, men de är fel (valgrind plockar bara string-concat-fallet).

#include <iostream>
#include <string_view>
#include <vector>

using namespace std;

void print_sw(string_view sw) {
        cout << sw << endl;
}

void all_ok() {
        print_sw(string_view{"a string literal"});

        string x = "This is long enough to bypass short-string optimization";
        string y = "Short";

        string_view sw = string_view{"a string literal"};
        print_sw(sw);

        vector<string_view> vec;
        initializer_list<string_view> initlist = { x, y };
        vec = initlist;
        for (string_view sw: vec)
                print_sw(sw);
}

void horribly_broken() {
        // using sting literal suffix creates temporary instance that broken1 outlives                                                                                  
        string_view broken1 = string_view{"a temporary string"s};
        print_sw(broken1);
         
        // ...still broken
        print_sw(string_view{"a temporary string"s});

        string x = "Foot ";
        string y = "gun!";

        // string concatenation creates temporary string, which broken2 outlives                                                                                        
        string_view broken2 = string_view{x + y};
        print_sw(broken2);

        // still broken
        print_sw(string_view{x + y});

        initializer_list<string_view> initlist;
        // The C++ Standard does not guarantee that std::initializer_list supports assignment in a meaningful or safe way.                                              
        // This was the *only* case that the compiler warned about, but it does compile!!!                                                                              
        initlist = { x, y };
        vector<string_view> vec = initlist;
        for (string_view sw: vec)
		print_sw(sw);
}

int main() {
	all_ok();
	horribly_broken();
}

Skulle inte kompilera i Rust och skulle inte vara en bug i något språk med GC då temporära objekt inte går out-of-scope där så länge det finns referenser.

Även C är långt bättre än C++ här. För skulle man göra motsvarande i C skulle man ha betydligt större varningsflaggor att man gör något korkat då C inte har några implicita anrop. Just implicita anrop är en foot-bazooka i C++.

Det funkar tyvärr inte så. Det finns så mycket som sker under runtime som inte enkelt går att förutse vid compile-time.

IBM utvecklade en tid en mjukvara som hette Purify. Det var som en slags debugger som man attachade till sitt program och som sedan kunde berätta vilka allokeringar som låg kvar och aldrig frigjordes. Men det var oerhört komplicerat, slöade ned ditt program mycket och det var dyrt.

Valgrind är ett ofta använt alternativ som i alla fall löser tillgänglighet och pris…