Inlägg

Finns en regel inom utveckling rent generellt; Ju kraftigare hårdvara vi får tillgång till, desto latare blir utvecklarna.

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!

Mitt bästa tips är att skapa något praktiskt, med ett syfte. Sen googlar du dig igenom varje hinder på vägen. Ett bra sätt att lära sig!

Exempel: ett python skript som laddar ner alla bilder från en webbaddress och zippar ihop dom.

Sedan ett webb backend (typ django?) som kan ta requests på webbadresser att ladda ner bilder från, och skickar tillbaks ett token. Detta token kan sen användas för ytterligare requests för att se om arbetet är klart eller få progress, samt få en nedladdningslänk till zippen med bilderna när det är klart.

Detta är bara ett random exempel, det bästa är om du hittar ett exempel som hjälper dig själv i vardagen.

Vill du faktiskt dra nytta av att du använder ett native språk så _vill du_ hantera minnet själv. Du vill kunna göra det för att hantera minneslokalitet, undvika onödigt frekventa eller små allokeringar, optimera minnesaccess för cache coherency/locality och så vidare. Det finns ett väldigt brett spann på kodkvalitet när det kommer till C/C++, och du kommer _aldrig_ att uppnå dom högsta nivåerna om du är lat med din minneshantering. Du _VILL_ veta precis hur var och när ditt minne allokeras, läses, skrivs, fetchas till cache på olika trådar och så vidare. Bra eller dåligt skriven kod här kan vara skillnaden på flera storleksordningar i exekveringstider/prestanda.

Om du inte gör det kan du lika gärna använda C# eller ett annat högnivå-språk med GC, runtime/AOT/JIT osv. istället. Men oavsett blir du ju också kvar med usel prestanda i jämförelse som resultat.

Multimonitor kommer fungera med flera grafikkort, däremot fungerar billigare lösningar också, som till exempel DisplayPort splitters som faktiskt fungerar för att uttöka antalet skärmar (utan att bara mirrora).

Med det sagt, du kommer förmodligen inte få högre prestanda, om detta är något du är ute efter. Dom valen som finns för att få högre prestanda med två kort är:

1. NVLink, men detta fungerar bara mellan två grafikkort av samma modell.
2. Spel har support för att använda sig av mer än ett grafikkort samtidigt (till exempel, köra fysik simulationer på ett och rendera på ett). I praktiken är det en försvinnande liten del av spel som faktiskt stödjer detta.
3. Du kan assigna specifika grafikkort till specifika applikationer, dvs köra AI modeller på ett medans du gamear på ett annat.

Vet inte vad du förväntar dig att jag ska svara på sådant här dravel? Själv kodar jag en blandning av C++17/20.

precis så här. uppmuntrar slappa lata och ibland inkompetenta utvecklare, tror du verkligen att den resulterade koden blir gedigen med denna approach? skill issue att få minnes problem för att man inte använder smarta pekare dessutom, sånt sitter i ryggmärgen när man kodat ett tag.

låter denna kommentar sätta punkt på denna diskussionen för mig. vill du vara lat så kör hårt själv föredrar jag att göra saker ordentligt. enda sättet att få robust kod påriktigt..

Hade bjarne haft något annat i åtanke så hade bjarne implementerat det.

Jag förstår syftet med unique_ptr's, jag gillar det bara inte. Det uppmuntrar amatörmässig kod, och har således en kontraproduktiv effekt. Det är som sagt dessutom bara stödhjul. Nej, man behöver inte använda det, men det behöver faktiskt inte existera till att börja med.

Allt som hanterar minne i C och C++ arbetar med "råa pekare" på något lager. Allt ovanpå är helt enkelt extra komplexitet. Ibland är den komplexiteten en kostnad för funktionalitet som är befogad och bra, men i detta fallet är det en kostnad som kodmässigt inte tillför någon funktionalitet. Det tillför dock som du säger något till programmerare som väljer att vara lata och inkompetenta, men det är viktigt att komma ihåg att det har en kostnad för den resulterande kodkvaliteten också.

Jag tror att du saknar definitionen i ditt vokabulär av vad kodkomplexitet faktiskt betyder.

Vi tycks vara hyffsat oense om detta dock, och känner inte att vidare diskussion skulle tillföra mycket. Men råder dig att sätta dig in i C/C++ ordentligt, på hur det traditionellt används, och hur det används av veteraner inom spelindustrin till exempel. Nu låter jag säker inte jätte ödmjuk, men jag tror det kanske krävs mycket praktiskt erfarenhet av just C/c++ för att se poängen av jag försöker lyfta här.

En del av GPU drivrutinerna är en implementering av OpenGL, Vulkan osv. I Linux fall använder man Mesa för denna delen, som streamlinear stora delar av denna implementering. Men drivrutinen behöver ändå erbjuda en integration mot dessa lager.

Rent kodmässigt blir det högre komplexitet. Det är ett extra lager ovanpå vanliga pekare, med tillhörande regler, rekommendationer osv. Det tillför dessutom ingen konkret funktionalitet, mer än ett påtvingande programmerarbeteende, som inte alltid är positivt.

Google rekommenderar dessa stödhjul, eftersom att Google investerar mycket i billig arbetskraft i bulk, och som du säkert vet så får man vad man betalar för (inkompetenta programmerare). I google's fall så fungerar dessa stödhjul till att minska antalet buggar i koden, eftersom att en stor del av deras programmerare är inkompetenta techbros.

Smarta pekare finns endast till för att kompensera för osmarta utvecklare. Och dom gör i princip alltid kodbasen sämre, om inte annat för att det ökar komplexiteten i koden.

Embedded kännetecknas nästan alltid av begränsade systemresurser, men också möjligheter för hårdvaruspecifika optimeringar. Att använda något annat än ett native språk blir då ganska slössamt.

C och C++ hanterar tunga beräkningar precis lika bra som Fortran, som också är ganska nischat idag.

Dom försöker ändra C++ till något det absolut inte är; Ett högnivå språk. Det blir högre komplexitet, helt i onödan, och således ett sämre språk att jobba med.

Raw pointers (eller bara pekare) är vad C++ alltid har haft, och det finns inget fel med det. Det är lågnivå av en anledning och krävs en del kompetens för att inte göra misstag, men det är så det är tänkt från början. Unique_ptr är en krycka för n00bs som vill hävda sig vara grymma programmerare. Det tillför ingenting annat än onödig komplexitet och en inbillad prestige.

Istället för att fråga varför pekare är bättre än "smarta pekare", ställ dig frågan varför behövs ens "smarta" pekare? Bortsett från shared_ptr och weak_ptr som kan vara användbara (dock i min åsikt så bör man oftast själv implementera sådan funktionalitet om man behöver det, då shared/weak är extremt generiska implementationer).

Det finns också en mörk sanning kring utvecklingen av C++, som involverar en trend av mental ohälsa som påverkar hela industrin negativt (som även påverkar C++ consortium). Detta är dock inget jag vill vidareutveckla i tråden, men eftersök själv i ämnet om du är nyfiken.

Försök inte laga något som inte är trasigt, säger jag bara

Tyvärr är det så. Har varit utvecklare i en spelstudio under EA, och kan säga att det är förmodligen 10x värre internt sett än vad man ser utåt. Corporate till 1000x, ingen själ tillåts i något spel.

Tror dom stängt av online servrarna.

Bra resurs!

Hur mäter sig RA3 mot RA1 och RA2? Vet att jag köpte Generals och Zero Hour men refundade när jag insåg att det inte hade multiplayer. Kanske köper det igen i och med detta