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

Beror på vad man är ute efter men det stora med C++26 (som ser ut och bli en mycket stor uppgradering) är enligt mig kanske inte det nya utan förbättringar i det som finns som gör det så mycket mer användbart. Räknar då in en del i C++23 för normalt tar det ett tag innan det går att använda det nyaste. Vi har fortfarande problem och använda saker i C++20 eftersom många typer av instanser i olika molnlösningar har fasligt svårt att hänga med. Kod kan till och med ha svårt att kompileras med C++17 som lägsta nivå.

Följande går nog att relatera till säkerhet. Enklare och/eller mindre kod för samma sak.

Förbättringar rörande områden constexpr och concepts som tar ner svårighetsgraden tror jag kommer uppskattas. Man behöver inte längre vara en ninja på templates för att lyckas skriva "cool" kod. Det som tidigare krävde detaljerad kunskap i hur C++ fungerar blir enklare. Mer och mer går att lösa utan templates.
Personligen så förbättringarna överlagring av index operatorn (multidimensional subscript operators) är efterlängtat, skrivs mycket beräkningskod går den och göra snyggare och enklare. Tills nu är det en hel del trixande för att få till sådan kod.
Deducing this kanske äntligen stöds av alla vanliga kompilatorer, en C++23 funktionalitet som tagit tid för dem att fixa. Gör det enklare att skriva en hel del kod men ser lite ovant ut

De två stora nyheterna med C++26 är annars reflection och contracts. Säkerhetsmässigt är contracts som hjälper, kommer säkert ta över mycket från assert och ser snyggare ut med förbättringar.
Kommer en ny header kallad <debugging>, känner inte till vad den är till för.

Frågade AI för vad jag vet så är contracts på vippen att vara färdigt, inte säker på att de spikat syntaxen men fick liknande exempel av AI

double square_root(double dX)
    pre (dX >= 0.0) // Precondition: Input must be non-negative
    post (r: r >= 0.0 && std::abs(r * r - dx) < 0.0001) // Postcondition: Result is non-negative and approximates sqrt(x)
{
    contract_assert(dX >= 0.0); // Redundant assertion for demonstration
    return std::sqrt(dX);
}

Det lilla r skall tydligen representera resultatvärdet. Tolkar jag rätt så standardiserar de makrot assert och gör det mer användbart.

Med contracts tycker jag nog att det finns än mer behov av att införa en till feature och det är att kunna skriva deklarationer och delar av definitioner av kod på flera ställen. Nu kan man deklarera så mycket om en metod för att kompilatorn skall veta hur den kan hantera och göra med metoden och det blir kladdigt. Det fyller inte så mycket av värde för programmerare när de läser koden och gör det hela krångligare. Exempelvis låter jag bli och använda attrbibutes av den anledningen. Vill gärna ha ett ställe där det är läsvänligt och då bara på det som behövs för att använda koden. Många kritiserar C++ för att de har en separat header (separering av deklaration och definition). Fattar inte det för det är bland det bästa i språket. Enligt mig är det mycket jobbigare att arbeta med kod där allt är samlat.

Delar kanske inte åsikten om att Java är något bra, java har en del mycket allvarliga designmissar (exempelvis allt är ett objekt...)

Men det du skriver om affärsintresse tycker jag ändå är viktigt att förstå, hur mycket inom it som handlar om affärsintresse för enligt mig så detta med säkerhetsproblem i C/C++ är enligt mig ett försök från affärsintressen att slå mot C/C++ eftersom det är ett språk som inte är "kontrollerat".

De största IT bolagen har samma ägarstrukturer så de jobbar ihop

Tror nog att säkerhet är lönsamt för att inte säga extremt lönsamt. Något de flesta företag lägger väldigt mycket pengar på

Senaste miljardföretaget från Sverige "recorded future"
https://www.investingothenburg.com/news/all-news/gothenburg-b...

Inte världens mest exalterande genomgång men han förklarar det nya i C++ som från början kallades för contracts men som bytt namn till contracts assertion - https://en.cppreference.com/w/cpp/language/contracts.html

Bra ändring, det mest förvånande är kanske varför det inte gjordes tidigare men möjligen ville man få med mer saker än bara förbättringar av hanteringen för assert

https://www.youtube.com/watch?v=u73ZB_vml_c

Tipsar om en fantastisk video där Casey Muratori beskriver en teknik som är typ +10 gånger (kanske 100..) bättre än allt annat. Men som är så svår att prata om.

Casey beskriver historiken bakom, han har grävt en del och tycker det var intressant i vad han hittat. Hur "kända" utvecklare som Bjarne och andra inte alltid haft rätt.

Tog ut den viktigaste delen i hela videon enligt mig:
45:29
A lot of this stuff when I diged into it, I was like, how come everyone doesn't know this because it's super cool. When he presented this paper, or I shouldn't say presented this paper, when he wrote this paper, he included discriminated unions in it. Tagged unions, whatever you want to call them. There's FP people out there in the audience are going to scream at me for using the wrong term, but you know what I'm talking about. Something that has a type in it and then subasses inside it. And you don't know which one you have until you look at the type. And then you can, you know, use whichever part makes sense for that type. And this is a super powerful programming. I use it all the time. And I think it's one of the best programming tools you have for things like dynamic polymorphism. I absolutely love it. It's in this paper in 1966, right? A long long time ago.

Vill man inte se hela så se i alla fall 40:00 - 50:00

Tycker själv att man skall kalla det här för data orienterad design och det går en del ut på att data alltid transporteras med metadata. Alla delar i dataströmmar har sin beskrivning.

Det här är också den säkraste formen av programmering eftersom data alltid kan kontrolleras oavsett var i systemet datat befinner sig. Det är mycket säkrare än någon annan teknik vad jag vet.

Kort svar för som du nämner är området stort han pratar om och framförallt svårt. Inte så att tekniken är svår för har polletten trillat ner är det enklare programmering. Men att ta sig dit är inte helt lätt. Det var lättare förr i tiden för att få flexibel kod (återkommer) i äldre miljöer, då var man nästan tvungen att tänka i de termer han pratar om.

Men viktigaste av allt enligt mig är att man kan referera till videon och visa att flera av "superhjärnorna" kanske inte haft 100% rätt. Därmed inte sagt att andra har rätt. Ofta när denna typ av diskussion tas upp kommer det genast upp flera stycken med länkar till kända utvecklare som säger "så här skall du göra". Sedan är diskussionen död.

Tolkar lite fritt vad han menade även om det med uteslutning går att förstå.

Kärnan i problemet: Att bygga kring fel domän

Tror han sa något om system domain eller domain, och när han säger domain tolkar jag att han menar "user domain". Alltså den domän programmet är satt att hantera. Och där nästan alla gör fel är att de bygger kod (klasser) runt "user domain".
Varför det är så illa är att den domänen normalt ändrar sig hela tiden, det är en domän utvecklare måste läsa på. Vad programmet används för är inte programmeringskunskaper utan just specifikt för varje applikation.

Istället för att bygga koden kring användardomänen, menar han att man bygger kod kring systemet (datorns system). Den typen av domän ändrar sig inte alls lika mycket, nästan inte alls. Skrevs applikation mot Win32 för 25 år sedan fungerar samma kod idag. Är koden däremot skriven mot hur en användardomän var för 25 år sedan har troligen applikationen jobbats med ordentligt eller så är koden död.

Det här är också orsaken till varför OOP blir så svårt när man väljer att bygga arkitekturen kring fel domän. OOP kopplar ihop mycket kod och när logiken ändrar sig blir det så mycket mer att skriva om. Det blir snabbt sådana mängder att hålla reda på att utvecklare tröttnar. Koden blir för tungjobbad och utvecklare behöver koncentrera sig bara för att komma ihåg alla hack.

Han beskriver då även tagged unions (taggad data). Och för att förstå varför det är så bra så behöver man förstå hur jobbigt det är att skriva om saker där mycket kod är beroende av varandra.
För när data är taggad kan man ofta göra små lösningar för att fixa edgecases mm, kanske bara lägga till en tagg för något speciellt och annan kod påverkas inte. Taggningen gör att kod blir så mycket mer flexibel på djupet.

Med taggad data kan man enkelt lägga till metod med if/switch sats eller lägga till i befintliga lösningar för att förändra utan att annan kod påverkas.
När koden är så flexibel är den också återanvändbar och det är där säkerheten kommer in. Kod som återanvänds är mycket säkrare än kod som inte gör det. Skulle ett fel inträffa smäller det ofta mycket snabbare eftersom samma kod körs hela tiden. Det blir också mindre mängd kod och mindre kod som gör mer saker är säkrare än mer kod som gör mindre saker.

Precis och som jag tolkar det så handlar det inte om arv utan området arven byggs kring. Hur koden byggs kring domänerna. Försöka bygga kod kring sådant som inte ändrar sig

Ja alltså det är egentligen en självklar lösning och vanlig, bl.a. i websystem mm. Men den går att applicera på så mycket mer

Angående Casey Muratori så pratade han strax under 2 timmar (tar inte med när han fick frågor) och tror inte han hade ett skrivet manus utan pratade fritt. Man behöver ju förstå kontexten och repeterar vad jag tycker var bra för oavsett var på nätet där man försöker diskutera sådant här så tycker 90% man pratar skit. Och beviset är länkar till andra som har hög status. De är duktiga men de är inte duktiga på allt.

Samma sak i denna tråd, det går inte att få in i skallen på en del att det finns säkrare sätt att koda än att bygga in säkerheten i kompilatorn.

Tycker exempelvis att "unit testing" är värdelöst, men det går inte att prata om det.

Nej det vet du inte

Och vi har precis diskuterat ett mycket svårt problem som blir enkelt med smartare arkitektur. Att unit-testing är värdelöst har samma grund som att bygga kod kring fel domän.
Kod lever när det handlar om anävndardomänen för det är väldigt få förunnat som skriver kod kring något som aldrig ändrar sig. Att unittesta saker som ändrar sig innebär bara mer kod att skriva om med ett värdelöst sätt att hitta buggar på. Har heller aldrig mött någon som kan skriva bra tester, att skriva bra tester är svårare än att skriva produktionskod. I princip varenda annan teknik för att testa kod är bättre, enda gången unit tester är bra för att testa att kod fungerar är om man vill skydda koden, låsa "fast den"

Nackdelen är att det tar tid att lära sig andra tekniker och eftersom de flesta utvecklare inte får lägga tid på att träna alternativa tekniker blir träningen lidande.

Angående att sådant här var så mycket lättare att diskutera förr jämfört med idag. Skulle man göra Win32 applikationer i C/C++ kände i princip alla till LPARAM and WPARAM och det var automatiskt ett naturligt sätt att tänka.
När man abstraherat bort underliggande teknik får utvecklare inte kontakt med sådant och känner därför inte till det.

Vill understryka att jag absolut inte är emot att testa kod. tvärtom så anser jag att det är så viktigt att kod skall testas att man behöver välja bättre teknik än vad unit-test är. unittester är för dåligt.

Utvecklare som sätter likhetstecken mellan "inga unit-tester" = "ingen kontrol" har inte prövat annat för att säkerställa koden.

Enligt mig skall kod designas utifrån att den skall skall vara säker, man väljer till och med lösningar för att säkra koden,

Skriver jag C++ kod så är den marinerad med assert eller för att ta javascript, där är det massor console.assert. Varenda programmeringsfel bör plockas genom att koden kontrollerar sig själv.

De två stora problemen med unit-tester är att de fångar för lite fel och gör koden mycket mer trögjobbad och det i sin tur leder till sämre kvalitet.

Man kanske då undrar hur jag vet det här? Ganska enkelt att testa genom att se vilka som får slita med buggar i deras kod.

Vet utvecklare som tycker unit-tester är superviktigt och samtidigt print-debuggar

Det där är inte billigt, säker kod måste vara lättarbetad. Desto mer du fångar i utvecklingsfasen desto billigare blir det.

Nämner två saker som jag inte tror är så vanliga.

Normalt ligger mitt fokus på att arbeta bort alla möjliga beroenden som går. Är man ny i programmering och jobbar med mig tror jag de har svårt att förstå varför jag skriver kod på ett visst sätt. Men det har med ovanstående att göra, att varje del i koden skall vara lätt och byta ut. Var därför min post där casey marutori beskrvier "tagged unions", så ser min kod ut men det är fasligt svårt att förklara för utvecklare. Det går inte in, har försökt massor av gånger. Några få fattar men de flesta begriper aldrig.
Försöker också skriva program så jag kan själv kan använda den. Det innebär att jag kan lägga in funktionalitet i koden som inte har något med applikatinens funktionalitet att göra, bara att jag behöver den i utvecklingen. Då måste jag köra koden hela tiden som jag också jobbar i och det brukar alltid vara en stor vinst när utvecklare också använder koden de jobbar med.