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

Det som beskrivs in den här videon är alltså fel enligt dig?

Även den här länken har missuppfattat
Imperative vs Declarative Programming

Jag förstår din poäng, men du missar en detalj: Många bäckar små.

Windows 95 rekommenderade specifikationer var en ancient singlecore 386 på 12.5MHz, 4MB arbetsminne, och 50MB diskutrymme.

Windows 11 rekommenderade specifikationer är modern dualcore 2000 MHz, 4000MB arbetsminne, och 64000MB diskutrymme.

Nog finns det vissa förbättringar här som befogar dom ökade kraven, men om 80% av koden är skriven slappt som du säger, så är det inte jättekonstigt att tänka sig att en majoritet av dessa ökade krav kommer från slappt skriven kod.

Detta är inte bara tillämpbart för Windows såklart, detta gäller nästan all mjukvara idag. Desto kraftfullare hårdvara vi får, desto slappare blir utvecklare. Och jag hatar det!

Tänk vad mycket prestanda som ligger på bordet här, som blir helt bortslösat på slappt kodhantverk.

Är programmering bara ens dagjobb och inget mer, dvs. man vill bara få arbetsdagen klar, man skiter i kvalitet på denna nivå, ja då är säkert (o-)"smart" minneshantering jättebra.

Men bryr man sig det minsta om hantverket man utför så ger man mer effort än såhär, tycker jag. Tänk om alla utvecklare var lika mycket neuropatiska autister som jag själv, och la 15% mer arbetskraft på att alltid göra saker ordentligt? Kan du tänka dig hur mycket processeringskraft, minne osv. vi hade haft idag? All mjukvara hade varit sinnessjukt snabb i jämförelse med skräpet som finns idag.

Utopiskt, javisst. Men jag tycker ändå man kan försöka bryta denna lathetstrend.

Tillägg: Och skiter man i detta, ja men använd C# eller Java istället. C++ ger dig ingenting i dessa fall!

Företag med kodbaser i C++ definerar definitvt hög prestanda som ett bra mått på kodvalitét. Samma företag premierar också utvecklare som inte lever enligt någon 80/20-regel. Man väljer liksom inte C++ om ens enda mål är att implementera lite businesslogik med kort utvecklingstid.

Varför skulle det vara lättare eller korta tiden?

Jag kan ta ett exempel med annat språk för att beskriva problemet.

Python räknas ofta som ett enkelt språk, behövs knappt programmeringskunskaper för att åtakomma något i python och det behövs inte mycket kod heller om man lyckats leta upp bra bibliotek.

Superlätt eller hur eller kanske inte

För jag vill påstå att o-dokumenterad pythonkod där saker namngivits efter domänen är bland det svåraste som finns för andra utvecklare att sätta sig in i.

Pythonkod kan lätt bli helt omöjlig för andra än den som skrivit koden att förstå.

Meningen var inte att jag skulle skriva en egen strängklass utan visa poängen. Jag vet att strängklasserna i stl är mycket optimerade och man behöver inte skriva en egen

Strängar brukar de flesta känna till så därför tog jag det som ett exempel

Möjligen men många vet fortfarande vad hungarian notation är och har två till markeringar av samma slag
*_s = static medlemmar eller metoder
*_g = globala variabler eller metoder
*_d = debug variabler eller metoder

Finns några regler till och de finns där för att ta ner vad man ibland kallar för "cognitive load". Programmeraren skall inte behöva memorera något utöver att följa koden i debug.

Om jag säger så här, man kan inte skriva för få assert. Assert är ett superbra komplement för att säkra koden. Men de här kan vara rätt slarviga, det gör inte så mycket och håller man på och testar kod, det råkar smälla så kan man lägga till mer assert då och ytterligare säkrar upp.

Jag personligen lägger inte så mycket tid på att fundera ut vilka assert jag tar med mer än de som jag kan tycka behövs just då när jag skriver koden.
Jämför lite med att skriva test. Test tar inte i närheten av alla fel som kan uppkomma men en del tycker det ändå är viktigt att skriva tester. Med assert behövs knappt tester för assert tar mer
Istället kan man fokusera på att skriva tester som kör produktionskod och jämför resultat eller liknande

Och förhoppningsvis dyker det snart upp en strängklass för utf-8 för det saknas om den inte nyligen dykt upp. En sådan har jag behövt skriva och det är faktiskt en väldigt bra övningsuppgift, och svår sådan.
utf-8 krånglar till det ordentligt för en del saker samtidigt som man får bra förståelse för varför vissa saker ibland måste optimeras genom att anpassa koden

Handlar inte om att avfärda någon som idiot. Handlar om att sätta en högre ribba för vad som betraktas som acceptabelt.

Mina kommentarer handlar om C++ funktionalitet som är utvecklade specifikt för att fungera som kryckor/stödhjul för lata utvecklare. Handlar inte om att avfärda utvecklarna eller att låta nedsättande, handlar om att kritisera utvecklingen av C++ och trenden av lata utvecklare i stort.

Sammanhang är viktigt.

Sånt här kommer med erfarenhet, för mig sitter minneshantering i ryggmärgen. Det är en tröskel att ta sig över och sen måste man hålla sig lite slipad för att inte bli rostig, men det blir en ickeissue med tid och erfarenhet!

Tar du spelbranschen som exempel så blir dessa saker alltid viktiga. Ta ett partikelsystem eller ett poolat system av dekaler som exempel, gör du den lata approachen så får du mycket stuttering och höjda frametimes, och begränsar antalet partiklar avsevärt. Gör du det ordentligt istället så kommer du knappt märka systemen i din profiler, trots att du kan ha 10x så många partiklar på skärmen samtidigt.

Hm, utf8 är ju Unicode? Håller med om att utf8 bara är att betrakta relevant för encode/decode från andra källor. Personligen brukar jag köra UTF32 för mina interna strängrepresentationer (som behöver ha hela Unicode set supportat). Det blir ett 4 bytes heltal för varje kod, så smidigt att slicea och indexa sen ser jag till att stödja UTF8 decode för att göra om ASCII och andra char strängar till UTF32 (utf8 är ju najs på det sättet att det är bakåtkompatibelt och en bra ”catchall” för 1 byte per karaktär strängar)

Då är jag med, och håller med!

Det finns förövrigt C++ bibliotek för texthantering som gör saken väldigt enkel även i detta språket.

Har tittat på en del sådan lösningar i rust (intressant namnval , typiskt rust) och jag upplever den koden som klart svårare än vad jag kan göra i C++. Självklart har jag en bias men försöker tänka bort den.

I ett projekt jag sitter i nu, där använder vi två olika objekt som vi själva skrivit "överallt" nästan. De är rejält optimerade så internt i dessa är de självklart svårläst. Men de är testade och investerad tid i dem är tagen. Med dessa kan vi rensa upp massor av annan kod.

C/C++ kommer finnas kvar i minst 60 år till.

På C++ sidan var det nog '98 jag börja med. Var då mycket new och delete; lite templates etc.
I C++ som följer '17 standard är det extremt ovanligt med att att ens ser new och delete.
Man blir väldigt bra på att använda sdt::make_unique, sdt::unique_ptr och std::move istället.
Dock är visa containrar svåra att hantera. Blir lätt fel. Det är också väldigt ofta man ser folk säga den här är mest effektiv, syftar på big O, men i verkligheten är kanske en ren vektor bättre då den ligger bra i minnet och är snabbare att accessa. (en del cpu:er har enorma cacher idag också).

Tittar på på säkra system så finns det bra standarder så som MISRA. Tycker MISRA C++ inte är så tokig om man vill göra det lätt för sig. Dessa upplevs dock ofta som föråldrade av moderna programmerare.

Erfarenhet? Gör definitivt skillnad men många industrier vill 'skala'. Det är viktigare än kvalité; så om det inte finns någon som beställer att det ska vara säkert enlig 'X' så får du nog det som konsencus på företaget tycker är rimlig kvalité. Jag har hittills aldrig jobbat för någon som på 'riktigt' bryr sig om koden. (en lite tråkig känsla).

Rust kan nog alldeles utmärkt ersätta C++, men hittills så har jag bara sett lite verktyg i Rust. Det finns idag inget business case som skulle få mig att använda Rust. Har stött på lite ramkverk där man försökt varit cool och valt ett annat språk; vilket sen gör det jobbigt med resurs tillförsel när dessa slutar. Om jag hade ansvar för ett sånt område så är det tveksamt att jag skulle tillåta Rust enbart pga. att det inte används i så stor utsträckning ännu.

Webb-världen känns mer flummig där och vi kan Javascripta allt... Minne? vem f*n bryr sig?
Kraschar det så tar vi snabbt upp en till instans... bara det inte craschar för ofta.
Stora Embedded system kommer gå mot det också; det händer redan.

Kommer inte ihåg exakt men någon nämnde att xerox (kan ha fel namn) var först och att Charles Simony plockade upp ideen samt förfinade den lite.
Charles Simony är inte en verbalt utåtriktad person som jag uppfattat det. Han är typisk ingenjör så jag antar att detta är en ingengörslösning och bör läsas ur det perspektivet. Så har i alla fall jag tolkat det.
Vad många glömmer av när man lyssnar på "talare" är att utvecklare generellt är introverta. För varje utvecklare som gillar att snacka går det minst 10 introverta som ofta är duktigare än de som gillar att snacka.

Exempelvis så i kod hade Microsoft bland annat c* för variabler som på något sätt var en count (räknare). Skulle man på 90-talet skriva ett windows program men den tidens miljöer var det omöjligt utan Hungarian. Så mycket olika parametrar i en mycket spartansk utvecklingsmiljö kunde ingen utvecklare hålla reda på.

Eller så fanns VB (visual basic) för de som inte kunde programmera.

Simony vart Microsofts chefs-arkitekt och låg bakom Excel som är Microsoft utan konkurrens bästa projekt. Resten av office produkterna tog efter Excel. Innan hade Microsoft försökt i mer än 6 år tror jag att få MS Word att bli en konkurrent till WordPerfect. Koden var fruktansvärd. Efter Excel och deras "Api" skrev de om allt.

Jag tror att utan Simony hade Microsoft inte var de är idag, han är ingen idiot och då bör man också ha det i bakhuvudet när man läser om hans ideer.

Har lyssnat på några av hans få intervjuer i poddar med.

Angående länken så gissar jag att det är en översiktlig förenkling men om man läser det här

Borde man enligt mig kunna räkna ut syftet, det är tillräckligt
Speciellt nummer 1 och 2.

De som ogillar Hungarian vill plocka bort nummer 1 och observera beskrivningen "so that the programmer can remember the name.". Man vill alltså skriva kod som är svår för programmerare att komma ihåg. Om man tycker ovanstående beskrivning är ok

Python kodare brukar skriva kod för icke programmerare, Python är egentligen ett språk för de som inte tycker om att programmera men ändå måste få något gjort. Python kod som inte är dokumenterad är bland det mest svårlästa som finns även om det är så lätt så att en icke-programmerare kan skriva kod

Tycker jag redogjort i tråden nog varför jag tycker det är en dum grej. Det är ett extra lager komplexitet (i termer av kod inte prestanda eller genererad kod), och det uppmuntrar en att vara lat med minnet.

Det finns förövrigt tusen saker till som du missat i din lösning i hur man gör det rätt, och vad som är viktigt att tänka på. Att allokera minnet är bara en grej. Att göra det på ett sätt som läses, skrivs, fetchas till CPU cacher vid rätt tillfälle på rätt trådar osv kommer till.

Smarta pekare ger ingenting till erfarna utvecklare, för en kostnad av komplexitet och uppmuntran till industridestruktiva mönster

Problemet idag handlar istället om att programmerare får lära sig någon slags regel om hur lång en metod får lov att vara. Det är lika fel det. Bryta isär metoden endast för att den skulle nå någon slags gräns.

För att simplifiera min poäng i den här tråden lite, då jag känner att den leder till cirkulära diskussioner:

Smarta pekare (och mycket annat i nyare STL) tycker jag går att jämföra med stödhjul i motocross. Ja, det hjälper förmodligen mindre erfarna förare då det förhindrar att dom trillar om kull.
Men för erfarna utvecklare blir det istället ett hinder (pga reglerna det enforcerar i pekares fall). Dessutom får det en att ställa sig frågan, bör man inte förvänta sig mer för motocrossförare? Är det verkligen rätt väg att gå att uppmuntra detta ens för nybörjare? Förarna lär sig att köra med stödhjul, tills dom kommer till en bana där dom blir totalt demolerade pga stödhjulen, och att dom aldrig lärt sig något annat.

Som professionell motocrossförare (utvecklare) tycker jag det väldigt krasst är dagisfasoner med ”smarta pekare” och det stjälper mer än det hjälper om man kollar på effekten det har på hela industrin och hela ekosystemet av mjukvara som finns.

Och gillar du inte cross och bryr dig mer om att ta dig från punkt A till punkt B, så kan du köra en trygg stor säker långsam lastbil istället (C#, Java osv)

Får passa på och ge beröm för en mycket bra förklaring

OT
Tränade min son i fotboll för en del år sedan, när han var ung (8-12 år). Där gillade en del att dribbla och skjuta mål, passa var inte lika kul. Växte de snabbt kunde en enda spelare avgöra en match.

Var detta bra långsiktigt, för denna snabbväxande spelaren märkte snart hur andra växte ikapp. De andra hade tränat mer på försvar, att passa varandra och taktik.

Flera av de som vart stjärnor som unga slutade för det var inte riktigt lika skoj när de märkte att de inte längre klarade att springa igenom och skjuta mål.

Samma sak är det i programmering, eller annat om man vill bli duktig. Man behöver förstå vad man måste lära sig och där går det inte ta genvägar. Man måste träna