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

Permalänk
Medlem
Skrivet av serafim:

?? Sambandet med det jag skrev ??

Att mönster kan användas till MYCKET
Det pågår en diskussion om mönstret HN och överlagring där jag hävdar att mönster är lättare för utvecklare om de skall skala koden. Vår hjärna fungerar inte helt olikt där när du använt mönster för att hitta snabbare.

Huller och buller är inte snabbt

Permalänk
Medlem
Skrivet av klk:

Att mönster kan användas till MYCKET
Det pågår en diskussion om mönstret HN och överlagring där jag hävdar att mönster är lättare för utvecklare om de skall skala koden. Vår hjärna fungerar inte helt olikt där när du använt mönster för att hitta snabbare.

Huller och buller är inte snabbt

HN ett mönster? Det är en teknik för namngivning i programmering, inte ett designmönster.
B-träd är inte heller ett designmönster utan en indexstruktur för att indexera stora datamängder.

Permalänk
Skrivet av klk:

Huller och buller är inte snabbt

Nu måste jag fråga, du talar dig varm för data oriented design och hur snabbt det blir för att man utnyttjar cachen bättre. Om vi har ett ECS där objekten bara innehåller ett ID till sitt entry i tabellen, är inte tabellen normalt oordnad då, dvs. huller om buller?

Permalänk
Medlem
Skrivet av serafim:

HN ett mönster? Det är en teknik för namngivning i programmering, inte ett designmönster.
B-träd är inte heller ett designmönster utan en indexstruktur för att indexera stora datamängder.

mönster = regelbundenhet, återkommande, rutin, standard, trend och så vidare.

Du vet jag är uppväxt på den tiden men lärde sig tänka själv

Permalänk
Medlem
Skrivet av klk:

mönster = regelbundenhet, återkommande, rutin, standard, trend och så vidare.

Du vet jag är uppväxt på den tiden men lärde sig tänka själv

Det virrigt framställda är förmodligen även virrigt tänkt.

Permalänk
Medlem
Skrivet av Ingetledigtnamn:

Nu måste jag fråga, du talar dig varm för data oriented design och hur snabbt det blir för att man utnyttjar cachen bättre. Om vi har ett ECS där objekten bara innehåller ett ID till sitt entry i tabellen, är inte tabellen normalt oordnad då, dvs. huller om buller?

Beror på context, hur data skall användas och vad id är. Låt säga att id endast är en nyckel för att snabbt komma åt data, då ligger förmodligen mer information om datat någon annanstans. Hur vet en del i koden att den just vill komma åt vissa id (viss data). Om id också fungerar som en slags taggning, att man kan förstå vad det är för objekt så går det att göra mer om det behovet finns.

Inte säker på att jag uppfattade din fråga korrekt så får ursäkta om mitt svar inte stämmer

Permalänk
Medlem
Skrivet av serafim:

Det virrigt framställda är förmodligen även virrigt tänkt.

Kanske, beror ju på vad man gör av det men inom programmering är det extremt viktigt att tänka själv. Det är ju det som är så fantastiskt med yrket, hela tiden nya problem där utvecklare måste tänka ut lösningar. Självklart varierar det hur mycket frihet man har men har svårt att tänka mig att det finns något annat yrke där det går att få så mycket utlopp för kreativitet som programmering

Permalänk
Skrivet av klk:

Beror på context, hur data skall användas och vad id är. Låt säga att id endast är en nyckel för att snabbt komma åt data, då ligger förmodligen mer information om datat någon annanstans. Hur vet en del i koden att den just vill komma åt vissa id (viss data). Om id också fungerar som en slags taggning, att man kan förstå vad det är för objekt så går det att göra mer om det behovet finns.

Inte säker på att jag uppfattade din fråga korrekt så får ursäkta om mitt svar inte stämmer

Den bilden jag hade av ett ECS var att man ofta stoppade data i tabellen i den ordning objekten skapades och ID helt enkelt var indexet i tabellen. Även om du har nycklar bland datat i tabellen är väl tabellen i sig typiskt osorterad? Osorterat == huller om buller.

Jag vill bara vara lite putslustig och peka på motsägelsen:
DOD == Snabbt
DOD == Huller om buller
Huller om buller != snabbt.

Forget about it, det var inget viktigt.

Permalänk
Medlem
Skrivet av klk:

mönster = regelbundenhet, återkommande, rutin, standard, trend och så vidare.

Du vet jag är uppväxt på den tiden men lärde sig tänka själv

"Att tänka fritt är stort, att tänka rätt är större"

När man diskuterar ett område där det finns vedertagen terminologi så hjälper det väldigt mycket om alla inblandade
använder den terminologin istället för att, som du, använda orden med helt andra betydelser.

Permalänk
Medlem
Skrivet av klk:

När du skriver kod, vad tänker du på? Har du något du försöker tänka på för att koden skall se bra ut och fungera bra i resten av projektet?

Är det ett projekt där det redan finns en etablerad kodstandard så följer man den.
Annars så väljer man någon av de mer etablerade varianterna för hur kod skall se ut och följer den - och det kan variera från språk till språk hur konventionerna ser ut.

Så länge man är konsekvent så spelar detaljerna ingen större roll. Fyra tecken indrag eller åtta tecken indrag är inte viktigt. Om man
använder namn som is_ready eller isReady spelar heller ingen större roll. Det viktiga är att samma konventioner följs i hela koden - och inte ens det är egentligen himla viktigt även om det underlättar.

Permalänk
Medlem
Skrivet av klk:

Kanske, beror ju på vad man gör av det men inom programmering är det extremt viktigt att tänka själv. Det är ju det som är så fantastiskt med yrket, hela tiden nya problem där utvecklare måste tänka ut lösningar. Självklart varierar det hur mycket frihet man har men har svårt att tänka mig att det finns något annat yrke där det går att få så mycket utlopp för kreativitet som programmering

Stor kreativ frihet har man ju i de flesta konstnärliga yrkena och i många hantverksyrken. Och den kreativa friheten är kanske stor om man ägnar sig åt programmering för nöjes skull, t.ex. som hobby, men i större mjukvaruprojekt kan jag inte påstå att man har särskilt mycket utlopp för kreativitet. Där är man beroende av andra, av problemdomänen, programspråksvalet, m.m. och mycket av arbetet går efter erfarenhet och redan fastlagda algoritmer och rutiner.
Stor kreativ frihet hade jag när jag skrev webb-krälare åt ett projekt, d.v.s. program som sökte av webben efter viss typ av information men så småningom blev det rutin av det också. Men kul var det och det ska man inte underskatta, det får gärna vara roligt.
Också när jag skrev program för analys av storskaliga experiment kände jag till en början att jag hade stor frihet men så småningom blev det matematisk kunskap som krävdes och man hamnade i en stadig lunk i och med att man funnit hur man skulle realisera de matematiska ekvationerna i programkod.
I de flesta fallen gäller det ju att överföra en modell över en (begränsad) verklighet till ett datorprogram och det är mest i design- och modelleringsarbetet man har friheten. Väl framme vid programmerandet blir det ändå mest en jämn lunk.
Ibland kan det spetsa till sig men oftast är det när man ska hitta en bugg. Det kan vara lite speciellt.
Kreativitet kommer in då man ger sig på att lösa problem man inte tidigare stött på men efter många år i branchen blir det inte så ofta.

Permalänk
Medlem
Skrivet av WebbkodsFrilansaren:

Jag tror det är någon form av "pseudokod" reverse-engineered av personen ifråga? Eller är det där riktig C-kod trots allt? Jag tänkte att det var resultatet av någon kodkonvertering eller -transpilering?

Jag fick taskiga vibbar från ett gammalt jobb där en av systemprogrammerarna programmerade så.
Alla variabler hette "v"+ett ordningstal, alla funktioner hette f+ett ordningstal, alla funktioner som i princip fungerade som procedurer hette p+ett ordningstal, inga kommentarer eftersom han tyckte koden var självförklarande, "kommentarer är bara i vägen och gör att man inte får något flyt i läsningen av koden"
Å andra sidan kunde han på något mystiskt sätt sina program i detalj trots att det rörde sig om ett stort antal program.
Man kunde beskriva ett fel man upptäckt och han kunde svara något i stil med:
"Ah, troligen taskig initiering av v123 i modulen m22", och det han sa stämde i 9 fall av 10.
Men det var en mardröm för alla andra när de var tvungna att sätta sig in i hans program.