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

I klartext: om man läser alla inlägg härifrån och ett antal sidor bakåt så är det i princip bara Du som stämmer in på "VET hur man egentligen ska göra"-beskrivningen. Vi behöver inte lägga någon värdering i det. Så gott som alla andra ställer öppna frågor och motfrågor i hopp om att försöka förstå VAD det är du försöker säga.

Flera av oss är universitet-/högskoleutbildade ingenjörer och är sedan länge inpräntade med att påståenden behöver backas upp för att bära någon substans.

Vi har sett dina påståenden, det vi efterfrågar är substansen. Gör det saken tydligare?

Med samma logik borde det vara tydligt att fakta är vad som efterfrågas, faktan som underbygger dina åsikter (för åsikter som inte bygger på fakta skulle jag vilja klassa in i kategorin "känsla").

// 1: återanvänd tabell (flexibel tabell för att hantera tabelldata)
detail::columns* pcolumnsThread = new detail::columns{};
ptableLineList->to_columns( *pcolumnsThread );
std::unique_ptr<table> ptableLineListLocal = std::make_unique<table>(pcolumnsThread, 10, ptableLineList->get_flags(), 10);

// 2 argument objekt
gd::argument::shared::arguments arguments_({{"source", stringFile}, {"file-key", uKey}});
if( stringSegment.empty() == false ) arguments_.set("segment", stringSegment.data()); // Set the segment (code, comment, string) to search in
auto result_ = COMMAND_ListLinesWithPattern(arguments_, vectorRegexPatterns, ptableLineListLocal.get()); // Find lines with regex patterns and update the local table

// 3 Namngivna argument
 MESSAGE_Progress("", {{"percent", uPercent}, {"label", "Find in files"}, {"sticky", true}});

Kan du nu förklara hur detta är relaterat till DOD?

Ett faktiskt svar. Om jag förstått DOD rätt så handlar det om att fokusera på att data är cache line-optimerad så vi är någorlunda i linje med det svaret.

Så om vi utgår från vår nyfunna middle-ground för definitionen av DOD och tar en titt på dina andra påstående ihop med DOD:

Varför skulle DOD leda till mer återanvändbar kod om man stirrar sig blind på cache line-optimering istället för användarvänlighet och flexibilitet?

// 1: återanvänd tabell (flexibel tabell för att hantera tabelldata)
detail::columns* pcolumnsThread = new detail::columns{};
ptableLineList->to_columns( *pcolumnsThread );
std::unique_ptr<table> ptableLineListLocal = std::make_unique<table>(pcolumnsThread, 10, ptableLineList->get_flags(), 10);

// 2 argument objekt
gd::argument::shared::arguments arguments_({{"source", stringFile}, {"file-key", uKey}});
if( stringSegment.empty() == false ) arguments_.set("segment", stringSegment.data()); // Set the segment (code, comment, string) to search in
auto result_ = COMMAND_ListLinesWithPattern(arguments_, vectorRegexPatterns, ptableLineListLocal.get()); // Find lines with regex patterns and update the local table

// 3 Namngivna argument
 MESSAGE_Progress("", {{"percent", uPercent}, {"label", "Find in files"}, {"sticky", true}});

Vad i denna koden antyder på cache line-optimering?

Om man optimerar för cache line och försöker spara cykler för att bevara FPS i spel eller annan prestanda. Går det inte emot DODs designfilosofi om man spenderar extra cykler på att annotera redundant typinfo?

OK, då kör vi.

Min vanligaste form av återanvändning är utan tvekan funktioner.

Nu gör jag andra saker men mitt senaste stora mjukvaruprojekt var en simulator av framtida produkter. Jag, som en del av ett team på 8 till 10 personer, utvecklade och underhöll centrala komponenter till denna simulator. Dessa komponenter kom i olika smaker för att simulera olika versioner av dessa framtida produkter. Det förekom även experimentvarianter för att utvärdera om olika typer av ny funktionalitet skulle vara användbar eller inte.

Själva simuleringsramverket är i C och använder en poor man's OO-modell med strukturer av funktionspekare. Detta är bara en objektmodell som används för simuleringen, inget arv, men man kan förstås återanvända funktionspekare för objekt som har likartad funktionalitet. Våra komponenter skrivs mestadels i C men vissa bitar är i C++. Mindre tidskritiska delar skrivs i Python (interpretatorn integrerad i simulatorn). Pythondelarna använder arv för att återanvända kod som är gemensam för snarlika komponenter. Återanvändning av kod består av simuleringsramverket i sig, bibliotek med supportfunktioner som används av olika varianter av våra komponenter, Pythonmoduler. Våra komponenter återanvänds när andra team bygger olika simulatorer för olika versioner av framtida produkter.

Tidigare jobbade (20+ år) med ett stort C++-projekt. Där var återigen funktioner den tveklöst vanligaste formen av återanvändning. Sedan är det frågan om vad som var på andra plats. Här användes vi arv och templates för återanvändning av kod, men frågan är om det inte var mer återanvändning när modulen jag jobbade med återanvändes i alla våra produkter (ca 20).

I båda fallen är slutresultatet ett program som körs direkt från kommandoraden eller startas av ett annat program.

Hur återanvänder du kod?

// 2 argument objekt
gd::argument::shared::arguments arguments_({{"source", stringFile}, {"file-key", uKey}});
if( stringSegment.empty() == false ) arguments_.set("segment", stringSegment.data()); // Set the segment (code, comment, string) to search in
auto result_ = COMMAND_ListLinesWithPattern(arguments_, vectorRegexPatterns, ptableLineListLocal.get()); // Find lines with regex patterns and update the local table

Fråga: vad vinner man på att använda gd::argument::... istället bara för att göra detta som rimligen de flesta som kan C++ borde ha betydligt lättare att läsa/förstå?

// 2 argument objekt
std::unordered_map<std::string, std::string> arguments_{
    {"source", stringFile},
    {"file-key", uKey}
};
if (!stringSegment.empty()) {
    arguments_["segment"] = stringSegment;
}
auto result_ = COMMAND_ListLinesWithPattern(arguments_, vectorRegexPatterns, ptableLineListLocal.get());

Är gd::argument med DOD på något sätt?

Ge ett exempel på vad det är för JSON-filer du behöver parse:a om det ens är relevant om det är 32 eller 48 bytes per nod?
Dels får man in >100k sådana noder i vissa moderna CPUers L2$, dels så lär den relativa skillnaden det utgör av den totala mängd data som man ändå behöver jobba med vara ett avrundningsfel. Eller?

Att spel kan få stor utväxling på DOD är ju p.g.a att man där spara all relevant data "på rad" och man sedan kan t.ex. applicera förändring av position baserad på senaste frame-tid multiplicerad med aktuell hastigheter. Något som med DOD ligger på ett "bekvämt" sätt för att processas med SIMD (vilket spelar roll om det är ett gäng tuselentals till tiotuseltasl object).

Men processa JSON... Då har man ju ändå en pekare till själva strängen och kostnaden för parsning lär vida överstiga kostanden för att läsa de noder 32/48 bytes noder med meta-data.

Så i vårt språk(svenska) betyder "återanvända" att "använda på nytt". Exempelvis väldigt generellt skriven kod har ju större sannolikhet att återanvändas eftersom användningsområdet är större än låt säga ett nischat område(som kan optimeras pga sin avgränsning).

Lite som du är inne på med JSON-bitarna från Boost den är nischad till att enbart hantera JSON även om JSON och YAML är kompatibla representationsmässigt. Boost hade ju kunnat återanvända lexer, ha olika parsers och spotta ut samma AST(givet samma input så klart). Boost drog troligen gränsen för att enbart optimera för JSON vilket gör koden mindre återanvändbar men snabbare.

För att sammanfatta:

Återanvändbar är inte samma sak som snabb. Jag har inte format en åsikt så stark att jag skulle påstå att dom är mutually exclusive men min magkänsla säger att den ena oftast kommer på bekostnad av den andra.

Jag tolkar det som att DOD framförallt är pga hastighet och att det därför fått sådant dragning inom spelindustrin. Sedan så har jag en känsla av att betydelsen av DOD har blivit uppblåst av somliga personer eftersom man låter smart när man pratar om lågnivåoptimeringar. Nu bor jag i ett spelmecka och snackar förhållandevis frekvent med spelutvecklare och med vetskapen om deras arbetssituation(alltid skitstressigt) så har jag svårt att tro att någon skulle ha tid att prioritera sådana optimeringar. Det viktiga är att pumpa ut spel och är du utvecklar du långsamt så ryker du eftersom det står 500 andra sökande på tur.

Personligen har jag aldrig behövt bry mig om särskilt mycket om DOD, visst vi har tumregeln som att sortera struct-medlemmarna i fallande storlek så är du "good to go" eftersom man antar att utvecklaren inte placerar skräp i structen. För min del har det alltid varit viktigare med design så att man tänker på vart man kan och bör parallelliserar, tänka på minnesanvändningen, tänka på storlek, tänka på risken av sönderskrivningar, säkerhet osv. Jag tänker naturligt på datautformning men inte notoriskt eftersom det inte spelar roll för min del. Det viktigaste är att koden gör det den ska i en rimlig hastighet och är lätt att underhålla och är lätt utöka vid behov.

Precis så varför stirra sig blind på DOD och göra det till din religion?

I C++ finns en poäng om man stoppar in typer med icke-trivial dtor i en union. I det läget måste man ha någon form av tag/typinfo för att veta vilken dtor som ska köras när unionen går out-of-scope.

Men känner också: antalet gånger jag känt behov av "variant" är väldigt få. Har använt det ett par gånger i Rust, kommer inte ihåg exakt till vad längre. Finns fall där variant kan ha sina poänger, men känns som specialfall och inte normalfall.

Har i.o.f.s. använt C# DynamicInvoke på ett ställe i kodbasen jag sitter med nu, då kan man ha mottagare med konkret typ i signaturen istället för att de alltid ska behöva ta någon gemensam bastyp och down-casta. Lite åt samma håll, fast där behöver man typinfo på en funktion för att kunna matcha den med data vill skicka.

Den här tråden går ju i cirklar offtopic, så mitt (totalt onödiga) bidrag för ikväll blir att återposta(?) Andrew Kellys utmärkta video om Data Oriented Design (tillämpad i Zig-kompilatorn, med exempel i språket).

Det finns ju ett gäng sätt att implementera objektorientering/arv/polymorfism i C (eller i C++ om man insisterar på det), där de berömda tagged unions är ett.

Videon har bäring på de senaste sidorna i tråden mest för att Kelly i mångt och mycket totalslaktar sina egna tagged unions, till förmån för vad han kallar "encoding". Har man inte sett videon förut så ska man nog med stor behållning börja från början, annars börjar slakten vid ca 23:25 och fortsätter in i exemplen från kompilatorn.

(det finns en skjortvideo från i år också, den är också lite intressant om man inte ser världen i svartvitt)

Enda gången jag använt det var för att implementera ett Simula-programmeringsverktyg på Mac för många år sedan, måste varit MacOS 5.1 eller möjligen 6.0, alltså långt innan övergången till MacOSX (nuvarande MacOS). Systemprogrammeringen skedde i Object Pascal så för att mappa en del datastruktrer som var inbyggda i OSet och slippa ständiga konverteringar så definierade vi upp ett mellanskikt i varianta records i Object Pascal som vi sedan läste in i klasser i Simula, fullständigt osäkert, inga kontroller, men det fungerade. Grundsystemet för att få Simula att köra på Mac hade gjorts av entusiasterna på Lunds Universitet, Boris Magnusson och Göran Fries, det jag implementerade var alltså ett verktyg för att effektivt kunna skriva Simulaprogram som hanterade alla faciliteter i Macen inklusive alla inbyggda datastrukturer så att man kunde framställa fullödiga Mac-program med hjälp av Simula. Jag kallade det för Macintosh Simula Workshop en anspelning på Apples egna verktyg, Macintosh Programmers Workshop. Det här måste ha varit runt 1987 eller 1988. Avsikten var att KTH-studenter skulle kunna programmera Simula även på högre kurser, de hade använt språket på grundkurserna i programmering och man ville kunna fortsätta efter andra året utan att behöva byta språk. Det gjorde inget större avtryck förutom att det användes på KTH som satsade mycket på Mac och att jag fick presentera systemet på en Simulakonferens i Pilzen i dåvarande Tjeckoslovakien. Senare gick man över till andra programspråk och systemet föll i glömska. Det som var trevligt med systemet var att, förutom "klistermodulerna" i Object Pascal som mappade alla datastrukturer till Simula var hela systemet skrivet i Simula.
... Lång historia för att berätta om mitt sammanträffande med taggade unioner. Det är enda gången jag använt det. Jag har inte hållit på med programmering där jag tyckt de tillfört något sedan dess och då såg jag det som en nödlösning för att slippa skriva krångliga konverteringsfunktioner. Jag såg det mest som fusk (men fusk som funkade).

Det var inte frågan. Frågan var om och i så fall hur den är optimerad för DOD. För kan överhuvudtaget inte ser det.

Möjligen kan det finnas funktioner som förenklar DDD, men det är inte samma sak som DOD.

OK, så frågan kvarstår: kan du ge ett enda konkret exempel när det är viktigt att ha 32 bytes meta-data per nod jämfört med 48 bytes meta-data. Vad är det för typ av JSON-dokument man parsar då?

Nja, decoupling handla ju bara om att reducera sammanflätning mellan två (eller flera) kodblock(namespaces, moduler etc) med olika syfte. Det handlar ju snarare om att ha väldefinierade interface(inte OOP interface) mellan kodblocken. Du kan ju exempelvis ha en funktion som tar en struct eller en container(vec, hashmap) som argument då finns ju typinfon redan i argumentet utan att bidra till ytterligare coupling.

Den enda gången jag kan se det som aktuellt att ha en typinfon tillgänglig är om datan måste serialiseras pga att couplingen är över IPC eller liknande men är får du gärna fylla i vad du menar?

Nu har jag också sett videon. Även om jag inte har använt DOD själv, så bekräftade den att min bild av DOD stämde ganska väl. Encoding-tricken som eliminerade en bool ur en struct (human_with_braces) fanns dock inte i min verktygslåda. Om size var viktigt hade jag använt bitfields för att stoppa in den i samma ord som taggen.

Intressant att hans omskrivningar gav så stora skillnader i Zig-kompilatorn. Men gissningsvis består vinsten till stor del av att han helt enkelt strök en massa medlemmar i strukturerna. Att byta pekare till index krymper datastrukturerna, men att plocka bort data som i de flesta fall inte används måste vara ännu effektivare.

Videon avfärdade helt och hållet uttalandet från @klk om att man som utvecklare blir mer effektiv om man använder DOD. Om man måste använda hjärncykler till att analysera hur saker och ting bäst skall sparas i minne och vad som är den mest gynnsamma encoding man kan komma på borde det rimligen betyda att det tar längre tid att skriva kod för den som kör DOD jämfört med en traditionell OOP-design.

Lite relaterat till ovan: man sparar huvudbry om man håller sig till common sense. Att bara willy-nilly optimera lite random structar och förvänta sig någon mätbar prestandaökning är nog ett recept för besvikelse. Där optimeringar likt det som nämns i DOD-videon ovan faktiskt spelar roll är om det ligger i någon form av "kritisk loop" (och/eller massiva mängder data).

@Dimman Nej, nej, sunt förnuft har inget i denna tråden att göra. Här är det dogmatiskt tänkande och principfasthet som gäller. Att lyssna på motsidan och omvärdera sin världsbild, det är inget vi gör här.

Se nedan, blev helt galet skrivet. Har aldrig använt en explicit variant-typ i Rust.

@ båda: inser att det jag skrev blev galet, blir kanske så efter en lång arbetsdag...

Menade att "använt enums i Rust med associerade värden på ett sätt som man i C++ skulle kunna göra med t.ex. variants". Fast även det har förkommit rätt sällan i min kod.

Majoriteten av fallen är "typen är känd compile-time". Det riktigt vanliga fallet med "tagged enum" är Option<T>, som är definierad som en enum med medlemmar Some(T) och None. Då är det i.o.f.s. en standardtyp, inget jag definierat själv.

Edit: det skrivet. Kan kanske ha mer att bero på domänerna jag jobbat med i Rust så här långt. Har precis utvecklat en YAML-parser i C#. Input YAML, output en objekt-graf där alla ingående noder är definierad av YAML. Om den hade skrivits i Rust hade det nog blivit väldigt naturligt med tagged enums! T.ex. vid distinktion av YAML sekvens, mapping och scalar.

Vi brukade analysera programdelar med matematik, där vi försökte fastställa någon form av värsta- och bästa-fallsscenarior.
Utifrån kapitel 9 (om Asymptotiskt uppträdande, Knuth skriver bara "Asymptotics") i Knuths "Concrete Mathematics" kan man göra komplexitetsanalys av funktioner och t.o.m. hela program (för att förstå och helt anamma kapitel 9 bör man förstås ha tagit till sig matematiken och informationen i de övriga kapitlen). Sådana analyser visar att oerfarna (ibland självlärda) programmerare är särskilt dåliga på att inse hur illa det kan bli och har heller ingen bra uppfattning om vad man kan göra åt dålig kod.
Den bra koden skrivs av erfarna, välutbildade programmerare, gärna med matematik i bakfickan men även där kan man hitta fällor och då är matematiken verktyget för att hitta ställena man kan effektivisera.

Det finns förstås andra böcker. Man kan söka på "Computational complexity".
Några som jag minns som bra böcker:
Homer & Selman: Computability and Complexity Theory, relativt ny book
Jones: Computability and Complexity, gammal (96?97?)
Sipser: Introduction to the Theory of Computation
Arora and Barak: Computational Complexity

Den här av Maheshwari & Smid hittade jag när jag försökte hitta titlar på böcker, brukar bara komma ihåg författarna (det är så de är organiserade på min server) och den är gratis att ladda ner.