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

Det är väl inte unikt för varken C eller C++. COBOL används fortfarande flitigt inom bankvärlden om jag förstått det rätt. Erlang används fortfarande flitigt.

Företaget Turso publicerade en omskrivning av sqlite i Rust(limbo) för några månader som fått en del uppmärksamhet. Personligen kommer jag använda limbo över sqlite framöver. Detta framförallt pga att det är open-source och inte source available men att det är minnessäkert känns som en trevlig bonus.

Detta är väldigt motsägelsefullt om det är så effektivt så hade alla jobbat med C++. Vad är det för tävling? Prestandamässigt så skulle jag hävda att C++, Rust och Zig är likvärdiga. Tävlar man i minnessäkerhet så finns där lite som C++ utvecklarna kan göra.

Nu tror du att C++-utvecklare är några övermänniskor. Jag tror framförallt allt att nya utvecklare inte vill dras med legacy utan en uppenbar vinst så därför väljer dom hellre att lära sig Rust, Zig eller Go. Jag tror därför att det handlar mer egenintresse hos nya utvecklare än kompetensproblem.

Som du var inne på tidigare ... kan du försöka hålla dig till diskussionen om minnessäkerhet istället för att sväva ut om hur pass "duktig" man måste vara för att koda C++ och att det inte finns något annat som kan mäta sig med C++. Det börjar bli aningen tröttsamt. Speciellt med tanke på att du alltid kommer med extraordinära påstående som alltid saknar fakta.

Du har ju knappt kunnat hålla ett sammanhängande resonemang konsekvent genom hela tråden och jag har bett om data som backar dina extraordinära påstående och kodexempel som du enbart ignorerar så kanske inte så lägligt att vara nedlåtande.

Då får du vara väldigt mycket mer tydlig. Du skriver ett halvt inlägg om data alignment och sedan name-droppar du SIMD och C++ sedan vill du att jag ska förstå något godtyckligt scenario som du målat upp i huvudet?

Sedan låter detta som att du borde skapa en separat tråd för detta "Hur gör jag X i Rust?" för jag förstår fortfarande inte vad detta har med minnessäkerhet att göra.

Snälla @klk svara på frågorna som @orp ställer i stället för att komma med orelaterat dravel. Jag tror du kan utgå ifrån att vi alla är erfarna programmerare med god förståelse för både datorarkitektur och vad kompilatorn gör.

Implementationen av klasserna i moderna bibliotek brukar vara ganska duktig på att hålla sig inom en cache line i de fall då det går. Exempelvis tog Yoshman tidigare upp implementationen av string som sparar korta strängar "inline" i string-objektet medan minne till längre strängar allokeras separat.

Försöker du säga att du ser till att du har en data-layout som tar hänsyn till den hardware prefetching processorn gör? Hur vet du hur processorn gör? Hur portabelt och återanvändbart är det?

Om ChatGPT inte ljuger för mig, så kommer både JVMen och .NET runtime att se till att data som används i SIMD-operationer har ett alignment som matchar data-typens storlek. Om du ser en skillnad på 10X borde det inte bero på minnes-layouten.

Då du aldrig använt Rust gör massa fel direkt felaktiga antaganden.

T.ex. så postade du denna länk längre upp
https://linearb.io/blog/message-chains-code-smell
och hävdade att de som kodar i Rust ofta skapar "message chains". Nu är det tekniskt möjligt att göra sådant i Rust, men det är inte ett språk som explicit stödjer OOP och finns därför inget som tvingar en att trycka in allt i klasser likt C#/Java. Idiomatisk Rust innehåller inte "message chains".

Däremot, från din egen länk, så är det många som blandar ihop "message chains" (som den artikeln anser är "dåligt") med "pipeline-style" (som artikeln anser är "bra"). Pipeline-style är extremt vanligt i Rust-kod, då främst i form av filter/map/reduce/etc.

Än mer är detta trevligt då kod skriven på det sättet i Rust kan i många lägen väldigt enkelt ändras (minimal kodändring) så den effektivt utnyttja multipla CPU-kärnor, via ramverk som Rayon. C++ har ett embryo till liknande stöd i standardbiblioteket i form av execution policy, men i nuläget är Rust/Rayon både mognare, ger i nästan alla lägen bättre presterande resultat och långt enklare att använda på "rätt sätt" (i.e. inga data-race).

Alla systemspråk samt Java, C#, Go, m.fl. har alla det relevanta stödet för att undvika prestandaproblem som false-sharing i de fall man delar data mellan trådar på korrekt sätt.

Utöver det är det rätt lite man behöver bry sig om cache-line storlek idag. Om man gör saker som är extremt prestandakritiskt är det i så fall idag mer relevant att tänka på page-gränser som väldigt länge "alltid" var 4k, men som på ARM64 allt oftare är 16 kB (kan vara 4, 16 eller 64 kB och är upp till OS att välja vilken storlek en viss process har, MacOS kör 16 kB och Linux har allt mer börjat gå till 64 kB på servers då enbart 4->64 kB page storlek kan ge 10-20 % bättre prestanda i "minnes-tunga" laster).

90-tals CPU, visst. En modern CPU har en långt mer avancerad access-pattern detektor än så...

Så länge din stride är förutsägbar spelar dess värde rätt liten roll. Det relevanta att ta med sig från det är: en array är betydligt snabbare än en hashmap, trots att båda är O(1).

INGET här är något som ger C++ en unik fördel.

Exakt. Enda som möjligen man kan "hjälpa" med är att försöka hålla working-set på så få "pages" som möjligt. TLB-L1 är mer prestandakritisk i moderna CPUer än L1-cache för data/kod.

Så här krångligt är det att använda SIMD i C# för de riktigt vanliga fallen

        var a = new Vector3(1, 2, 3);
        var b = new Vector3(4, 5, 6);
        var dotProduct = Vector3.Dot(a, b);
        var crossProduct = Vector3.Cross(a, b);

Detta blir "handoptimerad" SIMD för de plattformar som .NET-runtime stödjer. Och tillskillnad från C++ där man måste välja om det ska vara SSE, AVX, NEON eller SVE2 etc när man kompilerar kommer detta välja "bästa val" när programmet körs (vid JIT).

Så i praktiken (är möjligt att skriva kod som väljer vid runtime även för C++, något som ramverk likt ISPC kan göra) kan just sådant vara snabbare hos plattformar som använder JIT.

använda Rust för att läsa/skriva minnes-mappad IO. Nedan skulle kunna vara en del till Rust-driver för någon ARM MCU

#![no_std]
#![no_main]
use core::ptr::{read_volatile, write_volatile};
#[repr(C)]
pub struct GPIO {
    pub moder: u32,
    pub otyper: u32,
    pub ospeedr: u32,
    pub pupdr: u32,
    pub idr: u32,
    pub odr: u32,
    // rest of memory mapped registers...
}
const GPIOA_BASE: usize = 0x4800_0000;
const GPIOA: *mut GPIO = GPIOA_BASE as *mut GPIO;
#[entry]
fn execution_starts_here() -> ! {
    unsafe {
        let moder = read_volatile(&(*GPIOA).moder);
        write_volatile(&mut (*GPIOA).odr, moder | 0x1);
    }
    loop {}
}

Hantera minnet själv är ibland en bra idé, och i enstaka fall en absolut nödvändighet.
Oftast är det en usel idé.
Sköta all minneshantering manuellt är en extra källa till buggar, och tar tid, energi, och uppmärksamhet från programmerare som tvingas hålla på och mickla med minneshantering istället för att koncentrera sig på det problem som programmet egentligen är till för att lösa.

Man kan jämföra det med att jobba i assembler jämfört med ett högnivåspråk.
Assembler ger ojämförlig flexbilitet, och enorma möjligheter till optimeringar. Men det är också mycket mer komplicerat att skriva program i assembler än i ett högnivåspråk, det blir lättare fel, och det tar mycket längre tid.

Gillar hur du cherrypickar ett quote och totalt ignorerar 95% övriga svar..
Kudos till er här inne som fortfarande försöker föra en saklig diskussion, jag hade gett upp för längesen

Kan och kan.
Om man stryker vissa äldre delar av C++, och kräver att programmerare enbart använder någon slags "Modern" C++. så är det väl möjligt.
Men då missar man en av de stora poängerna med att använda C++ idag, nämligen all den existerande C++ koden, och om man ändrar om språket så pass mycket att det har alla bra saker med Rust, så är ju frågan om det då finns någon anledning att använda C++ istället för Rust.

En hel del av det där har inte mycket med språket i sig att göra utan har mest med utvecklingsmiljön att göra.