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

Permalänk
Medlem
Skrivet av Yoshman:

OK, ge ett konkret exempel på hur du använder SOA i din kod. Är inte det lite utmanande när du samtidigt verkar gilla variants (antar att du kallar det "ha flexibilitet i datatform"...).

Exempel:
Har table klasser (tre varianter). Enklast att beskriva är att de fungerar likt en tabell i en databas.
Varje kolumn i tabellen har en specifik typ, primitiva typer har fasta längder (kompilatorn vet), men så finns det extended types, där måste längden finnas med. Ett värde skall också kunna vara "null", för att veta om det är null behöver den informationen också vara med.
Det är grunden så hur placeras den datan så en processor skall kunna jobba maximalt snabbt?
Kan man placera data i ett enda block gillas det av processorer. Beskrivande information (exempelvis om värdet i fältet är null eller har ett värde) kan inte blandas in direkt i data. Därför så istället för att placera beskrivande data i data så läggs beskrivande data på annat ställe. För att inte null information skall ta allt för mycket plats kan man använda bitar, men då finns också begränsningar. skall det bli lätt så är man begränsad till 64 kolumner (om alla bitar i ett 64 bitars tal används).

Så här kan man fortsätta och på det viset går det att få en mycket snabb teknik med återanvändbar kod för att hantera data i tabellformat vilket är mycket vanligt i applikationer. Ett objekt som kan ersätta i princip alla std::vector< valfri struct >

Permalänk
Medlem
Skrivet av Yoshman:

I Go är inte strängar bara UTF-8, de tar 16 bytes på 64-bit arkitekturer och 8 bytes på 32-bit arkitekturer (den senare är i praktiken bara relevant för MCUer idag, men Go används där också)

I Rust är string-slices (&str) 16/8 bytes på 64/32-bit medan mutable strängar (String) är 24/12 bytes. I de flesta fall jobbar man där med &str utom när man bygger strängarna. Här hålls också strängarna i UTF-8 format.

Varken Go eller Rust har lagt till så de kan överlagra metoder, utvecklare behöver minnas för mycket om koden och det fungerar inte när koden växer. Man kommer en bit men sedan blir det för mycket att hålla reda på

Permalänk
Datavetare
Skrivet av klk:

Varken Go eller Rust har lagt till så de kan överlagra metoder, utvecklare behöver minnas för mycket om koden och det fungerar inte när koden växer. Man kommer en bit men sedan blir det för mycket att hålla reda på

Nu har du skrivit det så många gånger och det känns fortfarande som galimatias. Vad menar du med "överlagra metoder"?

Av språken med statisk typsystem lär Go ha den mest flexibla varianten av polymorfism.

Rust har ett trait-system som inte är lika komplicerat som C++? Och Rust har också ett macro-system som på flera sätt är mer kraftfullt än det C++ har via templates.

Vad är det konkret man inte kan göra???

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Datavetare
Skrivet av klk:

Exempel:
Har table klasser (tre varianter). Enklast att beskriva är att de fungerar likt en tabell i en databas.
Varje kolumn i tabellen har en specifik typ, primitiva typer har fasta längder (kompilatorn vet), men så finns det extended types, där måste längden finnas med. Ett värde skall också kunna vara "null", för att veta om det är null behöver den informationen också vara med.
Det är grunden så hur placeras den datan så en processor skall kunna jobba maximalt snabbt?
Kan man placera data i ett enda block gillas det av processorer. Beskrivande information (exempelvis om värdet i fältet är null eller har ett värde) kan inte blandas in direkt i data. Därför så istället för att placera beskrivande data i data så läggs beskrivande data på annat ställe. För att inte null information skall ta allt för mycket plats kan man använda bitar, men då finns också begränsningar. skall det bli lätt så är man begränsad till 64 kolumner (om alla bitar i ett 64 bitars tal används).

Så här kan man fortsätta och på det viset går det att få en mycket snabb teknik med återanvändbar kod för att hantera data i tabellformat vilket är mycket vanligt i applikationer. Ett objekt som kan ersätta i princip alla std::vector< valfri struct >

Huvudsyftet med DOD i spel har varit att effektivt utnyttja SIMD, något som ofta underlättas rätt mycket av att köra SOA istället för AOS. Hur gör du det med vad som beskrivs det enklare att använda SIMD och hur använder du SIMD?

Eller är det bara ett sätt att försöka minska cache-missar? Det kan nog ge en del, men normalt sett är det främst ihop med SIMD som man blir rätt rejält begränsad av cache-missar i en modern CPU nu när OoO-fönstret blivit så brutalt stort.

Gissar du bara vad som är flaskhals, eller har en profiler faktiskt visat det du optimerar som en flaskhals?

Och framförallt, har du tagit ett steg tillbaka och funderat: "kan jag göra det här smartare i form av att inte göra beräkningen alls eller långt mer sällan"? Kommer tillbaka till detta för det har varit så många gånger under åren när jag optimerat saker där slutklämmen blivit: ingen poäng att optimera original low-level koden, fanns hög-nivå optimeringar som gav långt mer och med dessa dyker inte low-level delarna vi tänkte optimera längre upp som signifikanta i profilern.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Huvudsyftet med DOD i spel har varit att effektivt utnyttja SIMD, något som ofta underlättas rätt mycket av att köra SOA istället för AOS. Hur gör du det med vad som beskrivs det enklare att använda SIMD och hur använder du SIMD?

Eftersom det går att kopiera en hel rad eller flera rader som ett block är det lätt att få till SIMD. SIMD är framförallt viktigt vid större mängder data. Ta att dela upp arbete i trådar. 10 trådar där varje tråd kör sin tårtbit och när de är klara så skall data snabbt samlas i en huvudtabell

Skrivet av Yoshman:

Gissar du bara vad som är flaskhals, eller har en profiler faktiskt visat det du optimerar som en flaskhals?

Idag gissar jag, förr tittade jag ofta på assembler och kunde också använda profiler men kompilatorer idag är löjligt duktiga på att optimera kod med rätt flaggor. Och det skiljer också så mycket beroende på vad man ställer in så det tar mycket tid och granska.

Vet på ett ungefär vad kompilatorn klarar att optimera
Skulle inte kompilatorn klara av att kompilera bästa koden idag så vet man ibland på ett ungefär vad den kommer klara av snart

Exempelvis så äldre C++ bibliotek, den kunde ha assembler för att räkna längd på sträng, eller assembler för memcpy. Idag tror jag de flesta låter kompilatorn generera upp bäst kod

Permalänk
Medlem
Skrivet av Yoshman:

Nu har du skrivit det så många gånger och det känns fortfarande som galimatias. Vad menar du med "överlagra metoder"?

Det tar för lång tid för mig att beskriva och eftersom jag inte är i närheten att kunna förklara HN, hur det kan vara bra så kommer den biten definitivt inte gå och beskriva här.
finns mycket trick för att hantera kod

Permalänk
Medlem
Skrivet av klk:

Det tar för lång tid för mig att beskriva och eftersom jag inte är i närheten att kunna förklara HN, hur det kan vara bra så kommer den biten definitivt inte gå och beskriva här.
finns mycket trick för att hantera kod

Det hade ju varit bra om vi kunde hållit oss till etablerade termer och definitioner så behövs det inte förklaras så mycket.

Tror de flesta hört talas om HN så ingen mening med att förklara det. Är det overloading du syftar på med överlagring som i function overloading?

Permalänk
Medlem
Skrivet av orp:

Det hade ju varit bra om vi kunde hållit oss till etablerade termer och definitioner så behövs det inte förklaras så mycket.

Så här. Etablerade termer och annat är ofta anpassade så att så många som möjligt skall förstå, kan man inte göra sig förstådd på typ 10 minuter så är det bara att glömma och beskriva något online (finns så gott om "experter") som vet bättre.. Och de är snabba och beskriva vad som är bäst (enligt dem).

Det går inte att ha tekniska diskussioner när det blir invecklat

Angående överlagring så tänk på en telefonbok, hur kommer det sig att man klarar av och hitta och läsa en telefonbok trots tusentals sidor, spelar ingen roll och man ökar på antalet sidor, det går lika snabbt ändå

Samma sak med kod, vi människor är begränsade i hur mycket vi kan ha i huvudet samtidigt och hur mycket vi kommer ihåg. Och vad en person kommer ihåg, det vet inte en annan.

Möjligen finns någon supermänniska som kan minnas hur mycket som helst men den har inte jag sett så tills dess går det faktiskt att se ganska snabbt på kod hur långt de kan komma.
Det är också därför jag sagt några gånger i tråden att viss teknik har svårt att skala, granskar man koden så kan man snabbt se hur långt de kommer komma även om det är mycket duktiga utvecklare. Har de inte tänkt på vår hjärnas begränsning i vad som går att minnas och ha kontroll över så kommer det inte så långt innan det börjar gå vääääääääääääldigt trögt.
Och när utvecklare får lägga så mycket energi på att bara komma ihåg saker så blir det tråkigt, det tar mental kraft som förstör arbetsglädjen

Permalänk
Datavetare
Skrivet av klk:

Eftersom det går att kopiera en hel rad eller flera rader som ett block är det lätt att få till SIMD. SIMD är framförallt viktigt vid större mängder data. Ta att dela upp arbete i trådar. 10 trådar där varje tråd kör sin tårtbit och när de är klara så skall data snabbt samlas i en huvudtabell

???

SIMD -> parallellism på en enskild kärna. Normalt av typen data-parallelism p.g.a. av "S" i SIMD.

MIMD -> dela upp arbetet i flera trådar. Stödjer både data-parallelism men också uppgifts-parallelism.

Med MIMD kan det vara prestandamässigt negativt att packa data allt för mycket, kan ge "false-sharing" vilket kan vara en rejäl prestandadödare (i sina värsta former går det då långsammare ju fler kärnor man slänger på problemet).

Så kör du SIMD eller MIMD?

Skrivet av klk:

Idag gissar jag, förr tittade jag ofta på assembler och kunde också använda profiler men kompilatorer idag är löjligt duktiga på att optimera kod med rätt flaggor. Och det skiljer också så mycket beroende på vad man ställer in så det tar mycket tid och granska.

Vet på ett ungefär vad kompilatorn klarar att optimera
Skulle inte kompilatorn klara av att kompilera bästa koden idag så vet man ibland på ett ungefär vad den kommer klara av snart

Exempelvis så äldre C++ bibliotek, den kunde ha assembler för att räkna längd på sträng, eller assembler för memcpy. Idag tror jag de flesta låter kompilatorn generera upp bäst kod

Här känns det igen mer som "vet på ett ungefär vad en kompilator från förra årtusendet klarar att optimera".

Just strängoperationer är något som rätt ofta är handoptimerade m.h.a. SIMD idag. Detta då egentligen inget av de "normala" språken har något vettig stöd för att uttrycka vad man vill göra som låter en kompilator göra ett bra jobb. Men är inte en omöjlig uppgift, Nvidias CUDA (GPU) och Intels ISPC (SIMD på CPU och GPU) är båda dialekter av C/C++ som har en semantik gör det möjligt för en kompilator att göra väldigt bra SIMD-kod.

Något kompilatorer/länkare är långt bättre på idag är att ta program som är uppdelade i många små (och enkla att testa...) delar, men ändå optimera det som-om allt är skrivet som en big-ball-of-mud.

Och kopplingen mellan "vilken assembler blir det / hur många instruktioner blir det" har allt mindre koppling till "hur snabbt körs detta på en modern CPU" då out-of-order fönstret blivit så gigantiskt. En människa ha extremt svårt att överblicka detta, även kompilatorer har problem då de bara har statiskt information och allt mer av prestandaflaskhalsarna är dynamiska (vilket är orsaken till varför JIT:ad kod (som JVM och .NET använder) idag kan vara snabbare än AOT (vilket C, C++, Rust, Go, m.fl. använder)).

Både C++ och Rust arbetar på ett grundläggande SIMD stöd i deras standardbibliotek. Rust-varianten är hyfsat färdig, men inte i skarp release än (men är alltid med och går att slå på med flaggor). C++ varianten är lite längre från att hamna i standarden, men går att test-köra. Ingen av dessa tar stödet lika långt som CUDA/ISPC, men ändå långt bättre stöd av vad som finns idag.

Skrivet av klk:

Det tar för lång tid för mig att beskriva och eftersom jag inte är i närheten att kunna förklara HN, hur det kan vara bra så kommer den biten definitivt inte gå och beskriva här.
finns mycket trick för att hantera kod

Tror alla som varit med i NH-diskussionen greppar vad NH är. Det jag tror ingen alls fattar är vad i HN du hävdar gör det så mycket enklare att "scanna stora mängder kod".

Och även här måste det ju finnas en eller flera specifika detaljer som gör C++ helt överlägsen allt annat då de överhuvudtaget inte har funktionen. DET måste vara trivialt att exemplifiera. Du har gjort ett par försök, alla har så här lång fallit totalt platt då du inte har koll på vad som faktiskt är möjligt i alternativen.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Så kör du SIMD eller MIMD?

Båda två

Skrivet av Yoshman:

Tror alla som varit med i NH-diskussionen greppar vad NH är. Det jag tror ingen alls fattar är vad i HN du hävdar gör det så mycket enklare att "scanna stora mängder kod".

Precis, därför är lite tekniskt svårare diskussioner omöjliga för alla vet redan. Att Microsofts ingengörer kunde vara så himla korkade och använda något så dumt som HN och med det lyckas producera Office och Windows, det är ju bara hur klantigt som helst

Lite stressad så kort svar

Permalänk
Datavetare
Skrivet av klk:

Båda två

Så hur hackar du SIMD-koden idag?

Assembler och/eller intrinsics så då gör din kod helt låst till en viss CPU ISA? Eller använder du ISPC (som i alla fall fungerar på alla relevanta varianter av x86 SIMD och ARM64 pre-ARMv9)?

Hur du hanterar MIMD har vi fått ett smakprov på. Tips: det är rätt mycket ett löst problem på ramverksnivå, använd ramverken då de är rätt mycket mer effektiva än ditt hemmasnickrade försök. Om nu inte huvudmålet är att lära dig, för finns rätt mycket att lära sig här (och något jag gillar då jobbat och även forskat en del kring detta).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Så hur hackar du SIMD-koden idag?

SIMD är ganska ovanligt att skriva kod för enligt mig, det får processorn avgöra eftersom det krävs bra förutsättningar för att göra det och det tar ofta för lång tid att pilla med sådant. Men vet jag om att det är någon passande operation där man bara skall gå igenom en lång rad med data, enkel operation och det passar för SIMD så gör jag en buffer (som är alignad), kopierar ett block eller möjligen läser minne från olika ställen och opererar på buffern. Tror det är kanske den vanligaste optimeringen och det är enkelt och debugvänligt.
Exakt hur beror på vad som skall göras. Ligger data i en lång rad perfekt för SIMD slipper man det men då bör man tänka igen hela lösningen och det kostar i tid och underhåll.
Risken med att skriva egen SIMD kod är eventuellt att nya processorer och kompilatorer plötsligt kan göra det bättre själva men så har man långsammare hårdkodad lösning.

Det vanligaste är vad jag tror att dra nytta av flera kärnor och kan man göra det så enkelt som möjligt underlättar det ordentligt. En del använder OpenMP eller liknande men jag tror att ofta så vet de inte om det blir snabbare, hade de mätt prestanda är det inte säker att den trådade delen är snabbare än en enkeltrådad.

Annars så senaste gångerna jag kollat genererad assemblerkod och haft optimering för SIMD så är kompilatorerna rätt duktiga på att hitta ställen lite över allt där de kan optimera. Men man bör ju veta att minnet ligger i cache, se till så det ligger där för annars blir det att elda för kråkorna
Av det jag sett kan kompilatorer idag räkna ut en hel del om kod för att förstå hur de skall processa information utan att programmeraren behöver "hjälpa" kompilatorn. Gjorde en del sådana test för några år sedan och det spelade minimal roll om jag "berättade" för kompilatorn att data låg på ett visst sätt jämfört med att den försökte själv.

Skrivet av Yoshman:

Tips: det är rätt mycket ett löst problem på ramverksnivå, använd ramverken då de är rätt mycket mer effektiva än ditt hemmasnickrade försök.

Jag tvivlar, det är så mycket säljsnack i sådant här och de testat saker med perfekta förhållanden. Sedan gör man något och märker att det inte fungerar så bra som de påstår.
Vet lösningar som var full med OpenMP kod och så togs det bort och det blev snabbare.

Permalänk
Medlem
Skrivet av Yoshman:

Och kopplingen mellan "vilken assembler blir det / hur många instruktioner blir det" har allt mindre koppling till "hur snabbt körs detta på en modern CPU" då out-of-order fönstret blivit så gigantiskt. En människa ha extremt svårt att överblicka detta, även kompilatorer har problem då de bara har statiskt information och allt mer av prestandaflaskhalsarna är dynamiska (vilket är orsaken till varför JIT:ad kod (som JVM och .NET använder) idag kan vara snabbare än AOT (vilket C, C++, Rust, Go, m.fl. använder)).

I GC kod blir det en soppa, där allokeras det ordentligt och utvecklaren har ingen aning om hur minnet hanteras. RUST tror jag är mycket bättre på att hantera eftersom utvecklare måste fajtas så med kompilatorn, det blir en naturlig del att lära sig om minnet (rust är bra på att lära utvecklare om minne). Kan mycket väl tänka mig att mycket i RUST är likt C++ men de måste för att bli helt likvärdigt gå unsafe.

Störst problem jämfört med C++ är enligt mig återanvändning. Rust orsakar så mycket andra problem för utvecklare att det blir för krångligt att också tänka på återanvändbar kod. GC kommer alltid varit långsammare oavsett vad någon tror.

Permalänk
Medlem
Skrivet av klk:

Så här. Etablerade termer och annat är ofta anpassade så att så många som möjligt skall förstå, kan man inte göra sig förstådd på typ 10 minuter så är det bara att glömma och beskriva något online (finns så gott om "experter") som vet bättre.. Och de är snabba och beskriva vad som är bäst (enligt dem).

Nej, en term är följande "uttryck som används inom ett visst verksamhetsområde och där har en speciell l. noggrant bestämd betydelse". Noggrant bestämt och vi använder dessa för att snabba upp kommunikationen, exempelvis kunde du säga regressionstest eller HN och alla vet redan vad det innebär utan att du behöver förklara mer.

Dom är alltså inte anpassade(enl. dig förenklade) för att så många ska kunna förstå dom.

Skrivet av klk:

Det går inte att ha tekniska diskussioner när det blir invecklat

Problemet är inte att saker är invecklade. Istället för att du går till Wiki-sidan för att kontrollera om "function overloading" är samma som du hade i åtanke och svara "ja, det är det jag tänkte på" eller "nej, jag tänkte på något annat" så får vi otekniska berättelser som nedan.

Det vill säga det går inte ha tekniska diskussioner när du berättar historier utan att anknyta dom till teknik...

Skrivet av klk:

Angående överlagring så tänk på en telefonbok, hur kommer det sig att man klarar av och hitta och läsa en telefonbok trots tusentals sidor, spelar ingen roll och man ökar på antalet sidor, det går lika snabbt ändå

Samma sak med kod, vi människor är begränsade i hur mycket vi kan ha i huvudet samtidigt och hur mycket vi kommer ihåg. Och vad en person kommer ihåg, det vet inte en annan.

Möjligen finns någon supermänniska som kan minnas hur mycket som helst men den har inte jag sett så tills dess går det faktiskt att se ganska snabbt på kod hur långt de kan komma.
Det är också därför jag sagt några gånger i tråden att viss teknik har svårt att skala, granskar man koden så kan man snabbt se hur långt de kommer komma även om det är mycket duktiga utvecklare. Har de inte tänkt på vår hjärnas begränsning i vad som går att minnas och ha kontroll över så kommer det inte så långt innan det börjar gå vääääääääääääldigt trögt.
Och när utvecklare får lägga så mycket energi på att bara komma ihåg saker så blir det tråkigt, det tar mental kraft som förstör arbetsglädjen

Detta sa inget om överlagring.

Permalänk
Medlem
Skrivet av orp:

Detta sa inget om överlagring.

Jo men man måste ju tänka lite. överlagring är en teknik för att skriva kod, denna teknik kan användas för att skriva kod så koden blir lättare att hantera. Det blir enklare att skriva kod efter fasta mönster och det är mycket viktigt

Permalänk
Medlem
Skrivet av klk:

Kan mycket väl tänka mig att mycket i RUST är likt C++ men de måste för att bli helt likvärdigt gå unsafe.

Sure, vad är problemet med unsafe? Det finns i språket av en anledning och det är ju för att användas.

Skrivet av klk:

Störst problem jämfört med C++ är enligt mig återanvändning. Rust orsakar så mycket andra problem för utvecklare att det blir för krångligt att också tänka på återanvändbar kod.

Detta låter mest om oerfarenhet. Jag uppfattar det som väldigt vanligt att man återanvända kod i Rust har väl rekord många paket(crates) till sitt förfogande och ligger väl på nivå med NPM. Det finns saker som är svåra att få till i Rust i dagsläget som async-traits (läs som interface med asynkrona funktioner/metoder) och då finns det en tillägnad crate, som löser detta, där användaren lägger till motsvarande ett macro på sitt trait(ser ut som en decorator från Python). Macrot kommer sedan modifierar funktion/metod-signaturen och wrappar-returvärdena på ett sätt så att ett icke-async-trait kommer fungera i async-förhållande. Det skulle jag ser som återanvändning.

Permalänk
Medlem
Skrivet av orp:

Jag uppfattar det som väldigt vanligt att man återanvända kod i Rust har väl rekord många paket(crates) till sitt förfogande och ligger väl på nivå med NPM.

Alla språk återanvänder extremt mycket, nästan allt. Det är ju just det som gör att det går använda andra språk, för det är nästan bara C/C++ som går att använda för att skriva kod helt utan att "återanvända" något alls. Men det görs självklart inte.

Men med återanvändning så menar jag bra återanvändning, inte att man bara pusslar samman vad som finns. Viktigt att kunna skriva kod som passar ihop

Permalänk
Medlem
Skrivet av klk:

Jo men man måste ju tänka lite.

Nej, det gjorde det inte eftersom du binder inte ihop resonemanget. Nu har jag försökt att tolka det du skrev så allt här efter är ett försök att bryta ner ditt inlägg för tolkning. Peka gärna ut vilka delar du tycker att jag lagt för lite vikt vid som hade rott hem din förklaring.

Skrivet av klk:

Angående överlagring så tänk på en telefonbok, hur kommer det sig att man klarar av och hitta och läsa en telefonbok trots tusentals sidor, spelar ingen roll och man ökar på antalet sidor, det går lika snabbt ändå

Du försöker inleda med en problembeskrivning och problemen är:
- Hur hittar man X bland rader och columner?
- Storlek (tusen sidor fast oviktigt), samma tidskomplexitet.

Skrivet av klk:

Samma sak med kod, vi människor är begränsade i hur mycket vi kan ha i huvudet samtidigt och hur mycket vi kommer ihåg. Och vad en person kommer ihåg, det vet inte en annan.

Vidare...
- "Samma sak med kod" så problemet är programmatiskt.
- "hur mycket vi kan ha i huvudet samtidigt", någon form av minnesbegränsning.
- "hur mycket vi kommer ihåg", någon form av lagringsbegränsning alternativt repetition av minnesbegränsning.

Skrivet av klk:

Möjligen finns någon supermänniska som kan minnas hur mycket som helst ...

Kim Peek, https://sv.wikipedia.org/wiki/Kim_Peek

Skrivet av klk:

... men den har inte jag sett så tills dess går det faktiskt att se ganska snabbt på kod hur långt de kan komma.

Det är också därför jag sagt några gånger i tråden att viss teknik har svårt att skala, granskar man koden så kan man snabbt se hur långt de kommer komma även om det är mycket duktiga utvecklare. Har de inte tänkt på vår hjärnas begränsning i vad som går att minnas och ha kontroll över så kommer det inte så långt innan det börjar gå vääääääääääääldigt trögt.
Och när utvecklare får lägga så mycket energi på att bara komma ihåg saker så blir det tråkigt, det tar mental kraft som förstör arbetsglädjen

Nu pratar vi om någons prestation och gått ifrån överlagringsbeskrivning genom problembeskrivning eller annan beskrivning.

Skrivet av klk:

överlagring är en teknik för att skriva kod, denna teknik kan användas för att skriva kod så koden blir lättare att hantera. Det blir enklare att skriva kod efter fasta mönster och det är mycket viktigt

Nu kommer vi äntligen till beskrivningen av överlagring. Beskrivningen är:
- Teknik för att skriva kod.
- Producerar kod som är lättare att hantera.
- Baseras på mönster(mycket viktigt!).

Om jag någonsin skulle ge exempel på en vag beskrivning så är ovan nog en stark kandidat.

Du beskriver ju inte:
- Hur löser tekniken din problemställning som du inledde med?
- Vad tekniken går ut på?
- Vad i tekniken får den att producerade koden lättare att hantera?
- Vilka kriterier uppfyller kod för att klassas som lättare att hantera?
- Vilka fasta mönster baseras tekniken på?
- Vad är ett "fast mönster" i kontexten? Regex, design-patterns eller något annat?

Permalänk
Medlem
Skrivet av orp:

- Vad är ett "fast mönster" i kontexten? Regex, design-patterns eller något annat?

Området är för stort för att diskutera här men om du jobbat med stl så kommer du märka att om du lärt dig en containerklass så vet du nästan hur alla de andra fungerar. Det vet du eftersom de följer samma mönster.
begin(), end(), emtpy(), size(), clear(), insert(), erase(), find() är vanliga. de finns inte på alla men så många olika metoder behöver man inte veta och det går ganska enkelt och lista ut resten.
Det blir också enklare att använda ett ord för metoden vilket är viktigt. Samma med konstruktorer och överlagrade operatorer. Man behöver inte minnas så mycket olika namn och det är lättare att få upp hastigheten när man slipper bråka med namnen

Skriver någon egna C++ objekt och följer namnstandarden är det lätt för andra utvecklare som kan stl och förstå objekten

Ovanstående var alltså ett exempel på hur man förenkla arbetet med kod

Permalänk
Medlem
Skrivet av klk:

Området är för stort för att diskutera här men om du jobbat med stl så kommer du märka att om du lärt dig en containerklass så vet du nästan hur alla de andra fungerar. Det vet du eftersom de följer samma mönster.
begin(), end(), emtpy(), size(), clear(), insert(), erase(), find() är vanliga. de finns inte på alla men så många olika metoder behöver man inte veta och det går ganska enkelt och lista ut resten.
Det blir också enklare att använda ett ord för metoden vilket är viktigt. Samma med konstruktorer och överlagrade operatorer. Man behöver inte minnas så mycket olika namn och det är lättare att få upp hastigheten när man slipper bråka med namnen

Skriver någon egna C++ objekt och följer namnstandarden är det lätt för andra utvecklare som kan stl och förstå objekten

Hur hör detta ihop med din överlagringsteknik? Samt hur hör det ihop med din problembeskrivning i din beskrivning av din överlagringsteknik? Dvs hitta X bland rader och kolumner med konstant tidskomplexitet med minnesbegränsning.

Permalänk
Medlem
Skrivet av orp:

Hur hör detta ihop med din överlagringsteknik? Samt hur hör det ihop med din problembeskrivning i din beskrivning av din överlagringsteknik?

Som jag skrev tidigare, den här diskussionen går inte att föra i sådant här media. Det blir för mycket bös och går ändå inte att förklara

Permalänk
Medlem

När jag först påstod att inget i ditt tidigare inlägg beskrev överlagrings så svarade du med:

Skrivet av klk:

Jo men man måste ju tänka lite. överlagring är en teknik för att skriva kod, denna teknik kan användas för att skriva kod så koden blir lättare att hantera. Det blir enklare att skriva kod efter fasta mönster och det är mycket viktigt

Efter att jag bröt ner ditt inlägg så skriver du:

Skrivet av klk:

Som jag skrev tidigare, den här diskussionen går inte att föra i sådant här media. Det blir för mycket bös och går ändå inte att förklara

I inlägg 1 så hävdar du att du redan beskrivit tekniken om man är smart nog att förstå det.
I inlägg 2 så skriver du att det inte går att diskutera tekniken efter att jag bevisat att inlägg 1 var falsk.

Förstår du varför jag tror att du trollar eller är en oseriös aktör? Jag var nästan övertygad att du var ett troll (typ en gymnasieelev med chatgpt). ChatGPT hade förklarat feberyrandet som fått diskussionen att hopp från ämne X till Y till Z utan att riktigt bearbeta något ämne.

Hade du inte bara kunnat hålla dig till tekniska diskussioner? Förklara tillvägagångssätt, processer osv, istället för saker som "Angående överlagring så tänk på en telefonbok ...".

Om du tycker att X är skit och du har en egen teknik som är bättre men inte går att förklara på ett forum, skulle du inte bara kunnat undvika att dra igång sådan diskussioner eftersom det ändå inte leder någonstans?

Permalänk
Medlem

@klk Blir bara lite nyfiken gällande ett inlägg några sidor tillbaka om HN och hur du resonerar där. Om jag inte missförstod det så förespråkade du bIsReady framför is_ready; strider inte det mot din första grundlag om att skriva vettig kod från början, dvs med vettig kod så är det redan självklart?

Jag har svårt att se hur en "is ready"-funktion/metod skulle returnera annat än sant/falskt och fortfarande klassas som vettig. (Förtydligande: logiskt sant/falskt så att en if (is_ready) alternativt if (is_ready()) fungerar oavsett datatyp)

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av Dimman:

@klk Blir bara lite nyfiken gällande ett inlägg några sidor tillbaka om HN och hur du resonerar där. Om jag inte missförstod det så förespråkade du bIsReady framför is_ready; strider inte det mot din första grundlag om att skriva vettig kod från början, dvs med vettig kod så är det redan självklart?

Jag har svårt att se hur en "is ready"-funktion/metod skulle returnera annat än sant/falskt och fortfarande klassas som vettig.

Om du väljer enklaste möjliga exempel så kommer du inte få någon logik på HN. För de är korrekt, alla förstår "is_ready". Problemet är bara att kod är inte så enkel, kod är väldigt mycket mer komplex och du väljer inte stil för det enklaste, du väljer stil för det svåraste (borde göra i varje fall).

Små korta metoder kan man skriva hur värdelöst som helst, det går ändå att förstå. Menar inte att man skall slarva men det går

Permalänk
Medlem

Jo, men nu var det ju du som valde exemplet och inte jag. Jag ställde bara frågan kring ditt exempel eftersom det var just ditt eget exempel Upplever lite magnetpolsskifte i svaren.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av klk:

Som jag skrev tidigare, den här diskussionen går inte att föra i sådant här media. Det blir för mycket bös och går ändå inte att förklara

Denna sorts diskussion är faktiskt perfekt för ett forum, här har man möjlighet att skriva ned exakt och precist vad man menar, man kan förklara vilka definitioner för något man använder, ställa och svara på väldigt specifika frågor för att förtydliga exakt vad man menar, följa upp på andras tankar och berätta var man haft fel eller på vilket vis man blir misstolkad osv.

Allt detta sker också asynkront, så man har väldigt mycket tid att skriva egna tydliga argument eller att läsa och förstå andras argument och frågor.

Till exempel skulle detta kunna hända:

  1. Man gör ett övergripande påstående så som att "Enhetstester är värdelösa", och det man menar är att i ens egen erfarenhet, för en viss (eller kanske majoriteten av) sorts programvara så ger inte enhetstester mer värde än vad de kostar osv.

  2. En medskribent på forumet tolkar detta som att du säger att "I alla tänkbara scenarion, har inte enhetstester något värde, och dom bör aldrig användas". Medskribenten påpekar att i fall där människor faktiskt riskerar att dö, avlida, skadas allvarligt på grund av buggar i koden, då är det faktiskt värt det "extra arbete" som det skulle innebära, och när man arbetar på ett visst sätt så är det kanske inte ens extra arbete

  3. Sedan när du läser detta svar, så har du möjlighet att svara och förtydliga, och säga att du förstår att i fall där människor riskerar att dö så kan det vara värt kostnaden. Sedan säga att du utryckte dig på ett dåligt och otydligt sätt för du tänkte inte just då på att det finns väldigt mycket kod som körs på andra ställen än vad du refererade till.

  4. Efter att du gjort detta förtydligande, så har du nu möjlighet att förtydliga i exakt vilka sorters use cases eller applikationer du faktiskt hade i åtanke med orginaluttalandet och så vidare, och diskussionen kan hållas på ett plan där alla skribenter har en gemensam förståelse av ramarna för diskussionen.

Det finns alltså i detta formatet oändligt med tid att göra sig förstådd tydligt.
Tex i en diskussion om A och B, så kan man skriva: "På grund av A så händer ofta B. Till exempel i denna anekdoten C så kan ni se hur A leder till B pga D".

Det som istället ofta händer i denna tråden är att du i ditt svar lämnar ute A och B, och svarar "i anekdot C händer D", och sedan räknar med att folk automatiskt ska veta vad ditt argument egentligen är.

Det kanske känns som att du sparar tid på att skriva på detta viset, men det leder istället till att diskussionen fraktaliseras iväg i oändliga sidospår att svara på istället.

Permalänk
Medlem
Skrivet av orp:

Förstår du varför jag tror att du trollar eller är en oseriös aktör?

Ja det förstår jag. det jag säger är inte samma som man får lära sig i skolan, eller läser som best practices och så vidare.
Den typen av kod som jag beskriver bör de flesta företag undvika, de bör undvika C/C++ för 90% av de flesta som jobbar med programmering har inte intresset som krävs för att förstå det jag pratar om.

Permalänk
Medlem
Skrivet av Dimman:

Jo, men nu var det ju du som valde exemplet och inte jag. Jag ställde bara frågan kring ditt exempel eftersom det var just ditt eget exempel Upplever lite magnetpolsskifte i svaren.

Det tror jag inte det var, att det var mitt exempel utan isåfall svarade jag på annan text. hade aldrig visat HN genom ett sådant exempel

Tänk på att jag pratar med många så det är inte lätt att följa.

Hade gärna tagit en djupare diskussion om HN men kanske passar bättre i annan tråd och då helst med personer som är intresserade

Permalänk
Medlem
Skrivet av klk:

Ja det förstår jag. det jag säger är inte samma som man får lära sig i skolan, eller läser som best practices och så vidare.

För mig så handlar det om att du påstår saker som är lätta att falsifiera samt att du säger det som att det är en objektiv sanning när det är högst subjektiva åsikter.

Skrivet av klk:

Den typen av kod som jag beskriver bör de flesta företag undvika, de bör undvika C/C++ för 90% av de flesta som jobbar med programmering har inte intresset som krävs för att förstå det jag pratar om.

Du pratar hela tiden om denna typen, enl. dig, unika scenarion men när du beskriver dessa mer konkret så låter dessa alltid extremt vardagliga.

Permalänk
Medlem

Har mycket svårt att begripa varför man ägnar sig åt att kasta ut påståenden som man sedan inte kan underbygga med vettiga förklaringar och sedan påstår att det man sagt är så svårt att beskriva i en sån här tråd på ett sånt här forum.
Hur kan man själv på ett effektivt sätt använda tekniker och metoder som man inte kan förklara?
Jag har ägnat mig åt programmering av stora, komplexa interaktiva webb- och databasdrivna applikationer med krav på så hög tillgänglighet som möjligt och med (potentiellt) obegränsat antal samtidiga användare och aldrig någonsin under realiserandet av dessa system har vi använt annat än vedertagna modeller för programmeringsarbetet. Några av de grundläggande kraven har alltid varit begriplighet och testbarhet. I det senaste projektet var mer än 60 % av den skrivna koden just testkod och i slutet av vajre arbetsdag kördes samtliga tester för att verifiera att vi inte gjort bort oss. Alla programversioner sparades i ett versionshanteringssystem och alla testkörningars alla resultat sparades för maximal spårbarhet. Delar skrevs i Java, Groovy, Javascript, Python och integrationen av alla delar likväl som kommunikationen mellan dem testades så noga att vi kunde påvisa (och få åtgärdade) brister i serverprogramvaror som vi använde och även brister i minneshanteringen i Java.
Räknar jag alla programspråk som jag använt under mina runt 40 år i gamet, hamnar det runt 30 medan andra påstår att det är väsentligt flera och vi (man jobbar oftast inte ensam) har aldrig avfärdat ett språk på det sätt som du (@klk) gör. T.ex. har flera projekt framgångsikt skrivits i Python. Inte någonsin användes några obskyra obeskrivbara metoder eller tekniker, varför skulle man göra det, kommunikationen mellan projektmedlemmarna skulle ju inte kunna fungera.
Om inte du (@klk) är ett troll så måste jag dra slutsatsen att du antingen driver med övriga tråddeltagare eller inte riktigt förstår vad du själv skriver eller att du gör det men vill provocera fram en diskussion trots att den egentliga diskussionen ju faktiskt är över (den om utvecklingen med minnessäker programmering i C++)
Och varför påstå att folk ska undvika C/C++ på grund av att folk inte har tillräckligt intresse för att förstå vad du pratar om? Tvärtom har ju t.ex. @orp verkligen försökt förstå men du tar hans inlägg som kritik mot dig (en del är väl det men många är frågor i genuina försök att förstå).

Rättade ännu fler felstavningar