Permalänk
Medlem

Från Python till C++

Godkväll!

Jag är på jakt efter en uppdaterad bok om C++ som lär ut hur man skriver korrekt kod. Boken behöver inte förklara dom absoluta grunderna inom programmering.

Jag har grunderna i Python och har utvecklat ett enkelt 2D Spel och en enkel hemsida. Under dom projekten så jobbade jag med ett par olika librarys som Pygame, Matplotlib, Plotly & Django. Jag är absolut ingen erfaren programmerare men jag känner att jag har en stadig grund.

Är det någon som kan rekommendera en bok? Helst en bok som har med sig det goda som kom i C++17 & C++20.

Permalänk
Medlem
Skrivet av zonezoon:

Är det någon som kan rekommendera en bok? Helst en bok som har med sig det goda som kom i C++17 & C++20.

Grunderna du behöver är 99% likadana i äldre versioner som i C++20; Dvs. pekare, arrays, templates, const, arv, osv. Rekommenderar starkt att använda internetdokumentation för syftet att hålla dig uppdaterad med det senaste i C++ väg. Om du föredrar böcker för grunderna så borde dom flesta böcker göra susen.

Permalänk
Medlem
Skrivet av herkkä:

Grunderna du behöver är 99% likadana i äldre versioner som i C++20; Dvs. pekare, arrays, templates, const, arv, osv. Rekommenderar starkt att använda internetdokumentation för syftet att hålla dig uppdaterad med det senaste i C++ väg. Om du föredrar böcker för grunderna så borde dom flesta böcker göra susen.

Jag hör vad du säger. Anledningen till varför jag skulle föredra en uppdaterad bok är för att dom flesta C++ böckerna som lär ut grunderna i C++ går oftast över till Intermediate nivå i slutet, därav en uppdaterad bok för att lära sig så mycket nytt på en bok.

Permalänk
Medlem

Effective modern C++ går igenom saker som är nytt fram till C++14. Väldigt bra bok och rekomenderad av de flesta inom C++ industrin. Finns en del nya smarta saker i C++17 men inget som ändrar hur man skriver C++ som C++11 gjort.
Det är lite svårt att skriva en bok hur man använder C++20 iom att ingen har implementerat C++20 än. Det som finns är en massa bra talk på cppcon och cppnow från utvecklare som arbetar på C++20 featuresen.

Permalänk
Medlem
Skrivet av Frappee:

Effective modern C++ går igenom saker som är nytt fram till C++14. Väldigt bra bok och rekomenderad av de flesta inom C++ industrin. Finns en del nya smarta saker i C++17 men inget som ändrar hur man skriver C++ som C++11 gjort.
Det är lite svårt att skriva en bok hur man använder C++20 iom att ingen har implementerat C++20 än. Det som finns är en massa bra talk på cppcon och cppnow från utvecklare som arbetar på C++20 featuresen.

Jag ska kolla in boken du rekommenderade. Som jag sa, jag är ingen erfaren programmerare så dom nya smarta saker som lagts in kanske hjälper dom mer avancerade programmerarna.

Permalänk
Medlem

Det är nog relativt svårt att hitta en bra introducerade bok som dyker rakt in i 17/20 tyvärr. Jag skulle börja med en 11-bok och sedan bygga på med 14/17/20 i efterhand. De största skillnaderna skedde från C++ 03 till 11 imho. En bra bok som går igenom nyare grejer, utöver tipsen ovan, är ex "C++17 - The Complete Guide" om C++17.

En populär C++-bok för de med programmeringsbakgrund är "C++-primer." Den lär ut C++11 och undviker många anti-patterns som man kan hitta i andra läroböcker. Även om man programmerat innan kan den dock anses svår p.g.a dess upplägg (en sak i taget). Det är en rätt okej referensbok dock. "A tour of C++" är bra om man programmerat mycket innan, men ingen vidare nybörjarbok i sig, den går dock igenom koncepten i språket koncist och är bra om man är nyfiken på språket och ex kodat Java innan. En bra pedagogisk bok är "C++, early objects". Den lär ut "klassisk" C++ och lär ut en hel del dumma grejer. Men, att lära sig ngn C++ är bättre än ingen C++, och det kan vara en bra start bara man vet att man kan behöva lära om sig en del grejer längre fram. Chernos C++-videor på YouTube är väldigt bra med rätt längd där man kan ta saker i sin egen takt: https://www.youtube.com/watch?v=18c3MTX0PK0

C++ är ett väldigt stort språk och även om man är fanboy som jag kan det finnas lägen då andra, mindre, språk fungerar lika bra/bättre. Beroende på vad du vill göra kan det därför nästan vara lika bra att börja med C (exempelvis om du vill skriva egna moduler till Python). Grunderna har du stor nytta av i C++ då sättet att tänka och förstå pekare är väldigt bra att ha i bakhuvudet redan innan man lär sig C++. "Head first C" är en fantastisk bok som jag varmt rekommenderar.

För fler boktips om/för c++, se https://stackoverflow.com/questions/388242/the-definitive-c-b...

TLDR; fundera på om du inte ska börja med C istället, kolla då på "Head first C". Vill du lära dig C++, kolla på Cherno och läs "C++ Primer"

Permalänk
Medlem
Skrivet av macher:

Det är nog relativt svårt att hitta en bra introducerade bok som dyker rakt in i 17/20 tyvärr. Jag skulle börja med en 11-bok och sedan bygga på med 14/17/20 i efterhand. De största skillnaderna skedde från C++ 03 till 11 imho. En bra bok som går igenom nyare grejer, utöver tipsen ovan, är ex "C++17 - The Complete Guide" om C++17.

En populär C++-bok för de med programmeringsbakgrund är "C++-primer." Den lär ut C++11 och undviker många anti-patterns som man kan hitta i andra läroböcker. Även om man programmerat innan kan den dock anses svår p.g.a dess upplägg (en sak i taget). Det är en rätt okej referensbok dock. "A tour of C++" är bra om man programmerat mycket innan, men ingen vidare nybörjarbok i sig, den går dock igenom koncepten i språket koncist och är bra om man är nyfiken på språket och ex kodat Java innan. En bra pedagogisk bok är "C++, early objects". Den lär ut "klassisk" C++ och lär ut en hel del dumma grejer. Men, att lära sig ngn C++ är bättre än ingen C++, och det kan vara en bra start bara man vet att man kan behöva lära om sig en del grejer längre fram. Chernos C++-videor på YouTube är väldigt bra med rätt längd där man kan ta saker i sin egen takt: https://www.youtube.com/watch?v=18c3MTX0PK0

C++ är ett väldigt stort språk och även om man är fanboy som jag kan det finnas lägen då andra, mindre, språk fungerar lika bra/bättre. Beroende på vad du vill göra kan det därför nästan vara lika bra att börja med C (exempelvis om du vill skriva egna moduler till Python). Grunderna har du stor nytta av i C++ då sättet att tänka och förstå pekare är väldigt bra att ha i bakhuvudet redan innan man lär sig C++. "Head first C" är en fantastisk bok som jag varmt rekommenderar.

För fler boktips om/för c++, se https://stackoverflow.com/questions/388242/the-definitive-c-b...

TLDR; fundera på om du inte ska börja med C istället, kolla då på "Head first C". Vill du lära dig C++, kolla på Cherno och läs "C++ Primer"

Tack för det utförliga svaret. Anledningen till varför jag är sugen på C++ är pga spelutveckling. Man kan naturligtvis utveckla spel med hjälp utav andra språk också men jag känner för att ge C++ en chans. Jag har faktiskt kollat in C++ Early Objects med Tony Gaddins. Är det en bok du hade rekommenderat? Du skrev att det var en pedagogisk bok men den lär ut ”en del dumma grejer”. Vad menar du med det?

Om du hade behövt välja mellan C & C++, vad hade du valt?

Permalänk
Medlem
Skrivet av zonezoon:

Tack för det utförliga svaret. Anledningen till varför jag är sugen på C++ är pga spelutveckling. Man kan naturligtvis utveckla spel med hjälp utav andra språk också men jag känner för att ge C++ en chans. Jag har faktiskt kollat in C++ Early Objects med Tony Gaddins. Är det en bok du hade rekommenderat? Du skrev att det var en pedagogisk bok men den lär ut ”en del dumma grejer”. Vad menar du med det?

Om du hade behövt välja mellan C & C++, vad hade du valt?

C++ är utmärkt för spel och används brett i industrin. Samtidigt är färdiga motorer såsom Unity populärt även för relativt stora kommersiella titlar. Vill du göra spel kan en färdig motor såsom Unity vara bra för att komma igång och komma ngnvart. Risken med C++ är att man tröttnar för att man känner att spelet inte tar sig framåt utan man får lägga tid på att skriva stödjande funktionalitet och inte jobba med spelet. Om du dock är nyfiken på hur en spelmotor fungerar och vill lära dig göra en egen är C++ ett utmärkt språk. Så är även C. Många bibliotek/ramverk, t.ex. Vulkan är skrivna i C (men kan användas/anropas från C++). Mkt av den C++ som skrivs i industrin påminner om C, framförallt pga av tradition och av prestandaskäl.

Tony Gaddis C++ Early Objects är pedagogisk. Den lär dock ut en del "antipatterns" gällandes minneshantering, hur man hanterar resurser såsom filer och input från användare. Den är inte skriven med C++11 i åtanke och tar framförallt inte nytta av den funktionalitet som finns i standardbiblioteket. Det är dock saker man kan lära sig sen, det viktigaste är att man lär sig C++ .

Jag började med C och lärde mig på så sätt även grunderna i C++. Det hjälper framförallt att förstå hur minnet i datorn fungerar innan man tittar på objektorienteringen som finns i C++, och den lär man sig bra i C utan allt annat "krafs" i C++.

Hade jag varit du hade jag tittat på "Head First C" och sen "C++ Primer". Känner du att det inte riktigt lär dig det du vill kan du alltid titta på "C++ Early Objects". Chernos videor är som sagt också en riktigt bra resurs för att lära sig C++.

Permalänk
Hedersmedlem

@macher Unreal Engine kan ju "scriptas" i C++, så man kan absolut använda en färdig motor och ändå använda C++ till spelprogrammering.

Permalänk
Medlem

Jag har spelutvecklat lite med C++ och SDL (https://www.libsdl.org/) och tycker det är ganska bra nivå i början. SDL blir som en wrapper mot OpenGL och Direct3D och är relativt plattformsoberoende.

Om du ska börja med C++ och ren Direct3D på en gång är risken att den initiala tröskeln blir tuff.

Permalänk
Medlem
Skrivet av macher:

C++ är utmärkt för spel och används brett i industrin. Samtidigt är färdiga motorer såsom Unity populärt även för relativt stora kommersiella titlar. Vill du göra spel kan en färdig motor såsom Unity vara bra för att komma igång och komma ngnvart. Risken med C++ är att man tröttnar för att man känner att spelet inte tar sig framåt utan man får lägga tid på att skriva stödjande funktionalitet och inte jobba med spelet. Om du dock är nyfiken på hur en spelmotor fungerar och vill lära dig göra en egen är C++ ett utmärkt språk. Så är även C. Många bibliotek/ramverk, t.ex. Vulkan är skrivna i C (men kan användas/anropas från C++). Mkt av den C++ som skrivs i industrin påminner om C, framförallt pga av tradition och av prestandaskäl.

Tony Gaddis C++ Early Objects är pedagogisk. Den lär dock ut en del "antipatterns" gällandes minneshantering, hur man hanterar resurser såsom filer och input från användare. Den är inte skriven med C++11 i åtanke och tar framförallt inte nytta av den funktionalitet som finns i standardbiblioteket. Det är dock saker man kan lära sig sen, det viktigaste är att man lär sig C++ .

Jag började med C och lärde mig på så sätt även grunderna i C++. Det hjälper framförallt att förstå hur minnet i datorn fungerar innan man tittar på objektorienteringen som finns i C++, och den lär man sig bra i C utan allt annat "krafs" i C++.

Hade jag varit du hade jag tittat på "Head First C" och sen "C++ Primer". Känner du att det inte riktigt lär dig det du vill kan du alltid titta på "C++ Early Objects". Chernos videor är som sagt också en riktigt bra resurs för att lära sig C++.

Då gör jag nog som du säger. Jag har både hört och läst att många författare har svårt att lära ut minneshantering i sina böcker. Vissa förklarar bara väldigt ytligt, andra väldigt dåligt och ibland helt fel också. Om jag har uppfattat det rätt så är minneshantering en stor del i både C/C++ och man vill lära sig det rätt. Jag vet inte exakt vad jag vill göra inom spelutveckling, jag hade nog kunnat tänka mig göra lite allt möjligt, just för att jag tycker spel är intressant. Jag kör nog på ”Head First C”!

Återigen, tack för dina utförliga svar! Det hjälper oerhört mycket och det blev mycket enklare att välja. 😁

Permalänk
Medlem
Skrivet av Joppis:

Jag har spelutvecklat lite med C++ och SDL (https://www.libsdl.org/) och tycker det är ganska bra nivå i början. SDL blir som en wrapper mot OpenGL och Direct3D och är relativt plattformsoberoende.

Om du ska börja med C++ och ren Direct3D på en gång är risken att den initiala tröskeln blir tuff.

Jag hör dig! Du menar att SDL kan vara enklare att komma igång med jämfört mot OpenGL och Direct3D?

Permalänk
Medlem
Skrivet av zonezoon:

Då gör jag nog som du säger. Jag har både hört och läst att många författare har svårt att lära ut minneshantering i sina böcker. Vissa förklarar bara väldigt ytligt, andra väldigt dåligt och ibland helt fel också. Om jag har uppfattat det rätt så är minneshantering en stor del i både C/C++ och man vill lära sig det rätt. Jag vet inte exakt vad jag vill göra inom spelutveckling, jag hade nog kunnat tänka mig göra lite allt möjligt, just för att jag tycker spel är intressant. Jag kör nog på ”Head First C”!

Att förstå hur minne fungerar är en stor del av både C och C++, men de är också väldigt olika språk egentligen. C++ brukar ibland kallas för "C med klasser", men det är fel inställning att ha då sättet man skriver C och modern C++ är väldigt olika.

Jag skulle därför rekommendera att du börjar med C om du vill lära dig C, och C++ om du vill lära dig C++. Att börja med C i syfte att sen gå vidare till C++ är troligtvis ingen bra idé eftersom bra C ofta är dålig C++, så att kunna C är ibland mer ett hinder än till hjälp för att lära sig C++.

Permalänk
Medlem
Skrivet av perost:

Att förstå hur minne fungerar är en stor del av både C och C++, men de är också väldigt olika språk egentligen. C++ brukar ibland kallas för "C med klasser", men det är fel inställning att ha då sättet man skriver C och modern C++ är väldigt olika.

Jag skulle därför rekommendera att du börjar med C om du vill lära dig C, och C++ om du vill lära dig C++. Att börja med C i syfte att sen gå vidare till C++ är troligtvis ingen bra idé eftersom bra C ofta är dålig C++, så att kunna C är ibland mer ett hinder än till hjälp för att lära sig C++.

Vilket sätt att lära sig C++ som är bäst tvistar de lärde fortfarande, se ex: https://www.youtube.com/watch?v=fX2W3nNjJIo och https://www.youtube.com/watch?v=YnWhqhNdYyk och visst finns det (stora) skillnader mellan C och C++. Problemet jag observerat är dock att många aldrig fattar minneshanteringen med stack och heap, processen med kompilering och sen länkning och funktionspekare. Resultatet blir att man kan skriva C++-kod som kompilerar och går att köra, men man förstår sällan varför man ex. får vissa kompilerings- eller länkningsfel eller sidoeffekter av sin kod (varför programmet går x gånger fortare när man skickar runt const-referenser till en stor vector och inte skickar den by-value). Man förstår inte heller kopplingen mellan pekare (och referenser) och hur arv fungerar, hur virtuella funktioner och funktionspekare hänger samman, varför templates blir inline etc. Kommer man från C har man en hel del datorteknik med sig och sättet som framförallt objektorienteringen är implementerat i C++ fattar man mycket enklare (varför krävs vtable för virtuella funktioner ex). Det går att lära sig C++ utan att förstå det, men då är halva vinsten med att just koda C++ borta, om inte domänen kräver just det programspråket. Det går såklart att börja med C++ och sedan ta förståelsen i varför i ett andra skede. Men då tappar man många längs vägen som inte orkar ta tröskeln som C++ kan vara då man ändå kommer uppleva att man slåss mot kompilatorn.

Samtidigt är varje minut man sitter med C++ bra då det tar tid att lära sig och för att känna sig hemma med det, men av egen erfarenhet föredrar jag att börja med basala datatyper och pekare och sedan bygga på det med objektorientering och sedan templates, lambda, auto, decltype, smartpekare, även om det idag anses omodernt av många lärare som gärna introducerar STL och smarta pekare tidigt.

Den största fördelen med "Head First C" är framförallt hur du lär dig vad ett program är, hur det körs, hur det skapas m.h.a. av kompilering och länkning, samt hur stack och heap presenteras. Man kan mkt väl fortsätta med C++ efter att man läst första halvan, men första halvan gör introduktionen till C++ många gånger lättare imho.

Största fördelen med C++ är i mitt tyckte att det är ett flerparadigmspråk. Beroende på krav och målsättning kan man välja de tekniker som ex. löser problemet mest elegant eller ex ger bäst prestanda, även inom samma program vilket gör att den som är skicklig kan leverera en lösning snabbt, men som ändå är väl anpassad för hårdvaran den körs på i hot-pathen. Att lösa alla problem m.h.a funktionell programmering, eller helt sluta använda råa pekare och manuell minneshantering för att det är "omodernt" tycker jag är synd. Man ska använda rätt teknik vid rätt plats.

Permalänk
Datavetare
Skrivet av zonezoon:

Då gör jag nog som du säger. Jag har både hört och läst att många författare har svårt att lära ut minneshantering i sina böcker. Vissa förklarar bara väldigt ytligt, andra väldigt dåligt och ibland helt fel också. Om jag har uppfattat det rätt så är minneshantering en stor del i både C/C++ och man vill lära sig det rätt. Jag vet inte exakt vad jag vill göra inom spelutveckling, jag hade nog kunnat tänka mig göra lite allt möjligt, just för att jag tycker spel är intressant. Jag kör nog på ”Head First C”!

Återigen, tack för dina utförliga svar! Det hjälper oerhört mycket och det blev mycket enklare att välja. 😁

Har programmerat en hel del C++, både "gammel-versionen" och "modern C++" (C++11 och senare). En sak jag tyvärr måste nämna här är: att förstå C++ väldigt väl kan till viss del ställa till det i en spelmotor som UE4/UE5!!!

Minneshanteringen i UE4/UE5 är mer likt hur man jobbar i språk som Java/C#, så ur den aspekten är Unity och Unreal Engine rätt lika, än hur man jobbar med minne normalt sett i "modern" C++ (som i sin tur är väldigt lika hur man jobbar med minne i språk som Rust och Swift, skillnaden är att i C++ har man långt fler sätt att skjuta av sig både fötterna och huvudet ).

Om du primärt är ute efter att lära dig C++ specifikt för att jobba med spel och redan kan programmera i något annat språk kan du nog mer fokusera på just C++ i spel. Varför inte sätta dig ned med t.ex. UE4/5, det är en riktigt trevlig miljö som är gratis att komma igång med!

I UE4/5 kan du initialt jobba i Blueprints, en form av visuellt skriptspråk, och senare skriva om de delar där prestanda är kritiskt med C++ (då med UE-varianten av C++14/17, språkmässigt samma men ett annorlunda bibliotek och väldigt annorlunda minneshantering, det finns GC!).

Skrivet av macher:

Problemet jag observerat är dock att många aldrig fattar minneshanteringen med stack och heap, processen med kompilering och sen länkning och funktionspekare. Resultatet blir att man kan skriva C++-kod som kompilerar och går att köra, men man förstår sällan varför man ex. får vissa kompilerings- eller länkningsfel eller sidoeffekter av sin kod (varför programmet går x gånger fortare när man skickar runt const-referenser till en stor vector och inte skickar den by-value).

Sett många rekommendera att man bör föredra "by-value" nästan rakt av i "modern C++". Man lägger mer ansvar på kompilatorn om man skickar saker som std::vector<> "by-value", men om de faktiskt implementerar de möjligheter som finns blir t.ex. detta exakt samma sak och by-value variant är lättare att läsa/resonera runt

#include <numeric> #include <vector> int sum_by_val_vec(std::vector<int> v) { return std::accumulate(v.begin(), v.end(), 0); } int sum_by_ref_vec(const std::vector<int>& v) { return std::accumulate(v.begin(), v.end(), 0); }

Kompilerar man det t.ex. med clang 11.0 för ARM64 (ger mer lättläst assembler än x86_64, men även där blir det samma resultat i båda fallen)

sum_by_val_vec(std::vector<int, std::allocator<int> >): ldr x1, [x0] ldr x3, [x0, 8] cmp x3, x1 beq .L4 mov w0, 0 .L3: ldr w2, [x1], 4 add w0, w0, w2 cmp x1, x3 bne .L3 .L1: ret .L4: mov w0, 0 b .L1 sum_by_ref_vec(std::vector<int, std::allocator<int> > const&): ldr x1, [x0] ldr x3, [x0, 8] cmp x3, x1 beq .L9 mov w0, 0 .L8: ldr w2, [x1], 4 add w0, w0, w2 cmp x1, x3 bne .L8 .L6: ret .L9: mov w0, 0 b .L6

Med saker som link-time-optimization (LTO), vilket de flesta moderna C++ kompilatorer implementerar, kan man rätt mycket helt skita i att fippla med inline. Kompilatorn gör ofta ett bättre jobb än människor på att reda ut vad som bäst bör göras, med LTO kan kompilatorn göra "inline" även på lokala funktioner.

I vissa lägen kan även kompilatorer idag få bort indirekta hopp via vtbl, med LTO kan kompilator/länkare inse att det bara kan finnas en möjlig slutdestination för ett anrop

Självklart kan man inte helt ignorera lågnivå effekter om man vill pressa ur absolut allt ur ett system, men det som var sanningar för ett decennium sedan är inte alls lika självklart längre. Är man osäker på vad något resulterar i är det idag ofta långt snabbare att gå till Compiler Explorer och testa lite olika varianter än att försöka hålla varje "optimal" metod i huvudet (vad som är optimalt med dagen kompilatorer är ibland allt annat än självklart...).

Edit: och för att se hur icke-logiskt saker kan vara idag, testade exemplet ovan med Google-benchmark

#include <algorithm> #include <benchmark/benchmark.h> #include <numeric> #include <vector> constexpr uint32_t VEC_SZ = 10000; // Generate vector so the compiler cannot figure out the content compile time... std::vector<uint32_t> make_vec() { std::vector<uint32_t> v(VEC_SZ); std::iota(v.begin(), v.end(), 0); return v; } uint32_t sum_by_val_vec(std::vector<uint32_t> v) { return std::accumulate(v.begin(), v.end(), 0); } uint32_t sum_by_ref_vec(const std::vector<uint32_t>& v) { return std::accumulate(v.begin(), v.end(), 0); } // Apply sum to a "global side-effekt" so the function call cannot be optimised away uint32_t g = 0; void by_val(benchmark::State &state) { auto v = make_vec(); while (state.KeepRunning()) { g += sum_by_val_vec(v); } } BENCHMARK(by_val); void by_ref(benchmark::State &state) { auto v = make_vec(); while (state.KeepRunning()) { g += sum_by_ref_vec(v); } } BENCHMARK(by_ref); BENCHMARK_MAIN();

Rimligen borde båda vara lika snabba, men av någon anledning (har inte orkat kolla exakt orsak) så är by_val versionen konsekvent något snabbare! (Körde på min Linux dator som har en i7-8559U, är en NUC)

Running ./vec_bench Run on (8 X 4500 MHz CPU s) CPU Caches: L1 Data 32 KiB (x4) L1 Instruction 32 KiB (x4) L2 Unified 256 KiB (x4) L3 Unified 8192 KiB (x1) Load Average: 0.08, 0.07, 0.03 ----------------------------------------------------- Benchmark Time CPU Iterations ----------------------------------------------------- by_val 3932 ns 3932 ns 178388 by_ref 4804 ns 4804 ns 145770

Permalänk
Medlem
Skrivet av Yoshman:

Sett många rekommendera att man bör föredra "by-value" nästan rakt av i "modern C++". Man lägger mer ansvar på kompilatorn om man skickar saker som std::vector<> "by-value", men om de faktiskt implementerar de möjligheter som finns blir t.ex. detta exakt samma sak och by-value variant är lättare att läsa/resonera runt.

Det finns absolut lägen när pass by value är bättre, e.x. när move semantics kan användas. Framförallt kan det ersätta ut-parametrar. Och kompilatorn kan om den ser hur värdet används i funktionen i vissa fall ersätta pass by value med en referens. Just därför argumenterades ofta när c++11 var nytt att gå all in på pass by value, se ex: http://web.archive.org/web/20140113221447/http://cpp-next.com... . Herb Sutter m.fl. rekommenderar dock fortfarande const ref för de flesta fallen: https://youtu.be/xnqTKD8uD64?t=3066 .

Skrivet av Yoshman:

Med saker som link-time-optimization (LTO), vilket de flesta moderna C++ kompilatorer implementerar, kan man rätt mycket helt skita i att fippla med inline. Kompilatorn gör ofta ett bättre jobb än människor på att reda ut vad som bäst bör göras, med LTO kan kompilatorn göra "inline" även på lokala funktioner.

I vissa lägen kan även kompilatorer idag få bort indirekta hopp via vtbl, med LTO kan kompilator/länkare inse att det bara kan finnas en möjlig slutdestination för ett anrop

Självklart kan man inte helt ignorera lågnivå effekter om man vill pressa ur absolut allt ur ett system, men det som var sanningar för ett decennium sedan är inte alls lika självklart längre. Är man osäker på vad något resulterar i är det idag ofta långt snabbare att gå till Compiler Explorer och testa lite olika varianter än att försöka hålla varje "optimal" metod i huvudet (vad som är optimalt med dagen kompilatorer är ibland allt annat än självklart...).

Absolut, inline är idag bara ett sätt att ta sig runt ODR. Jag är kanske konservativ eller försiktig. För viktiga delar, hot-paths, litar jag inte på att kompilatorn (eller länkaren i fallet LTO) kommer optimera bort vtables etc. Jag försöker undvika "dyra" konstruktioner för de delar jag vet kommer vara varma. Självklart använder jag dock LTO samt alla optimeringsflaggor jag kan dock

Jason Turner visade att det går alldeles utmärkt att skriva ett spel till C64 med C++17 (https://youtu.be/zBkNBP00wJE), men man förlitar sig i det läget på att kompilatorn gör det den ska, och ofta krävs det att man "tunear" sin kod så att kompilatorn ser vilka optimeringar den kan nyttja. Olika kompilatorer kommer dessutom göra olika optimeringar (jmf asm från msvc och gcc ex). Den stora nackdelen med att förlita sig på modern C++ ihop med kompilatormagi är att koden blir "ogenomskinlig", du ser inte med ett snabbt ögonkast hur den här koden kommer köras på hårdvaran, vilket gör att många hellre väljer att programmera på ett sätt som många skulle kalla C-stil för kod där du måste veta att prestandan blir OK. Mike Acton har ett bra talk: https://youtu.be/rX0ItVEVjHc. Dagens kompilatormagi är dock fantastisk för all "vanlig" kod som nu kan skrivas lättläst men ändå rulla relativt snabbt.

Compiler Explorer är fantastisk, riktigt bra tips! (Snubben bakom CE, Matt Godbolt, har gjort ett par riktigt bra talks bl.a.: https://www.youtube.com/watch?v=HG6c4Kwbv4I)

Permalänk
Medlem

Det kan bli en chock att gå från Python till C++ och många fällor (saker man inte behöver tänka på i python men som man måste i C++). Ett tips är att kolla på Unity och C# som är betydligt snällare

Permalänk
Medlem

C++ är ett fantastiskt språk och ger en väldigt god inblick i hur programmering fungerar på ett djupare plan. Men det är också väldigt tidsödande att skriva program i C++ vs Python och andra "enklare" språk. Jag använder C++ på jobbet för att skriva riktigt beräkningskomplexa modeller, men i många fall är andra språk att föredra inom mitt område.

Med det sagt tycker jag absolut att du ska lära dig C++ och fixa en bok också där du kan lära dig grunderna. Språk ändras ju hela tiden så det viktiga är att lära sig hur man programmerar och grunderna i ett objektorienterat språk. Sen kan man googla sig fram till syntax och det som ändrats sen man höll på med det sist.

Permalänk
Datavetare
Skrivet av Herr Kantarell:

Det kan bli en chock att gå från Python till C++ och många fällor (saker man inte behöver tänka på i python men som man måste i C++). Ett tips är att kolla på Unity och C# som är betydligt snällare

Håller helt med att det är ett enormt steg att gå från Python till C++, det finns så många fler sätt att ställa till det i C++!

Däremot har jag svårt att se hur C# (och Java) är någon större förenkling över modern C++. C#/Java är absolut enklare om man bara vill ha jobbet gjort, men så fort man börjar lägga på restriktioner runt (mjuk) realtid och andra prestandakrav är min erfarenhet att det rätt snabbt kan bli enklare att göra det hela i C++.

Detta speciellt om man håller sig i kontext av spel och ställer de två mest populära lättillgängliga spelmotorerna mot varandra: Unity och UE.

Så fort projekten växer måste man börja tänka på hur man använder minne och för C#/.NET-programmerare måste man börja hantera och tänka på minne på ett sätt som inte alls är typiskt (för "generell" C#/.NET). T.ex. börja fundera hur man undviker heap-allokering (något som är långt enklare i "by-value" språk som C++ och Rust än i "by-ref" språk som C#, Java och de flesta språk). I C++ kan man med fördel hantera kortlivad data genom att lägga det på stacken.

JVM:er har sedan en längre tid tillbaka "escape analysis" som, om stjärnorna står rätt och man offrat till rätt gud (nåja, fungerar faktiskt riktigt bra i många fall!), automagiskt lägger kortlivade minnesallokeringar på stacken i stället för på heap:en. .NET runtime:en saknar än så länge sådant stöd (men det har jobbats på sedan 2018 och man verkar göra viss progress), dock en annan runtime i Unity så är väl ändå möjligt att det finns där (men verkar osannolikt, Microsoft har väsentligt större resurser avsatta till .NET).

Som nybörjare i dessa motorer är det faktiskt riktigt trevligt med Blueprints i UE4/5. Det är så nära "klicka-och-dra" programmering man kan komma och med lite eftertanke går det att komma rätt långt enbart med Blueprints. Fördelen med en sådan approach är att man väldigt gradvis kan introducera C++ i sitt spel och ändå ha något som är fullt "spelbart" hela vägen.

I ett större "jag vill lära mig skriva spel" kontext är C++ standardvalet idag. Personligen hoppas jag det på sikt går över mot Rust (Rust har samma "zero-cost-abstraction" mindset som C++ och även i praktiken är idiomatiska Rust program likvärdig i prestanda mot idiomatiska moderna C++ program, stora skillnaden är att det nästa är svårt att skjuta av sig fötter och huvud i Rust även om man försöker, slutar oftast med kompileringsfel. Att race-condition blir kompileringsfel i Rust är unikt och en dröm i dagens multicore-värld).

C++ väljer man nog enbart "för man måste" idag. Spelutveckling är att område där man av praktiska skäl rätt ofta fortfarande "måste" köra just C++, det p.g.a. att majoriteten av ramverken/motorerna som används är byggda i C++.

Det skrivet: finns självklart en rad fördelar med Unity över t.ex.UE. När man väl börjar använda C++ drar kompileringstiderna snabbt iväg. C++ är horribelt tungt att kompilera, C# (likt i praktiken alla andra språk) går väsentligt snabbare att kompilera.

Vill man även köra sitt spel på mobilplattformar har Unity historiskt varit en av de enklare miljöerna att jobba med. Just den aspekten har förbättrats rejält i senare versioner av UE4 samt i UE5.

Permalänk
Medlem

Galet bra respons från er alla! Efter jag har läst varje svar och förklaringar som ni har skrivit så känner jag mig som en riktig nybörjare… 🤣 Jag försöker hänga med och förstå vad ni menar men ibland tappar ni mig. Så som jag har uppfattat det så är C++ ett gigantiskt språk och kan ses som väldigt tungt att börja med. Jag vet inte om jag nämnde det tidigare men den väldigt lilla programmering jag gör ser jag enbart som en hobby. Jag vet inte själv riktigt vad jag vill göra inom programmering och jag vet inte vad man kan göra, så jag tänkte att spel kan väll vara roligt. Rätta mig om jag har fel, men C verkar vara enklare än C++ eftersom C inte har OOP. Jag kan mer än gärna börja med C om det skulle vara så, som sagt - allt det här är så fruktansvärt nytt för mig så jag har väldigt lite koll på vad som gäller och inte men hyfsat roligt tycker jag det är i alla fall.

Permalänk
Medlem
Skrivet av Yoshman:

Håller helt med att det är ett enormt steg att gå från Python till C++, det finns så många fler sätt att ställa till det i C++!

Däremot har jag svårt att se hur C# (och Java) är någon större förenkling över modern C++. C#/Java är absolut enklare om man bara vill ha jobbet gjort, men så fort man börjar lägga på restriktioner runt (mjuk) realtid och andra prestandakrav är min erfarenhet att det rätt snabbt kan bli enklare att göra det hela i C++.

Detta speciellt om man håller sig i kontext av spel och ställer de två mest populära lättillgängliga spelmotorerna mot varandra: Unity och UE.

Så fort projekten växer måste man börja tänka på hur man använder minne och för C#/.NET-programmerare måste man börja hantera och tänka på minne på ett sätt som inte alls är typiskt (för "generell" C#/.NET). T.ex. börja fundera hur man undviker heap-allokering (något som är långt enklare i "by-value" språk som C++ och Rust än i "by-ref" språk som C#, Java och de flesta språk). I C++ kan man med fördel hantera kortlivad data genom att lägga det på stacken.

JVM:er har sedan en längre tid tillbaka "escape analysis" som, om stjärnorna står rätt och man offrat till rätt gud (nåja, fungerar faktiskt riktigt bra i många fall!), automagiskt lägger kortlivade minnesallokeringar på stacken i stället för på heap:en. .NET runtime:en saknar än så länge sådant stöd (men det har jobbats på sedan 2018 och man verkar göra viss progress), dock en annan runtime i Unity så är väl ändå möjligt att det finns där (men verkar osannolikt, Microsoft har väsentligt större resurser avsatta till .NET).

Som nybörjare i dessa motorer är det faktiskt riktigt trevligt med Blueprints i UE4/5. Det är så nära "klicka-och-dra" programmering man kan komma och med lite eftertanke går det att komma rätt långt enbart med Blueprints. Fördelen med en sådan approach är att man väldigt gradvis kan introducera C++ i sitt spel och ändå ha något som är fullt "spelbart" hela vägen.

I ett större "jag vill lära mig skriva spel" kontext är C++ standardvalet idag. Personligen hoppas jag det på sikt går över mot Rust (Rust har samma "zero-cost-abstraction" mindset som C++ och även i praktiken är idiomatiska Rust program likvärdig i prestanda mot idiomatiska moderna C++ program, stora skillnaden är att det nästa är svårt att skjuta av sig fötter och huvud i Rust även om man försöker, slutar oftast med kompileringsfel. Att race-condition blir kompileringsfel i Rust är unikt och en dröm i dagens multicore-värld).

C++ väljer man nog enbart "för man måste" idag. Spelutveckling är att område där man av praktiska skäl rätt ofta fortfarande "måste" köra just C++, det p.g.a. att majoriteten av ramverken/motorerna som används är byggda i C++.

Det skrivet: finns självklart en rad fördelar med Unity över t.ex.UE. När man väl börjar använda C++ drar kompileringstiderna snabbt iväg. C++ är horribelt tungt att kompilera, C# (likt i praktiken alla andra språk) går väsentligt snabbare att kompilera.

Vill man även köra sitt spel på mobilplattformar har Unity historiskt varit en av de enklare miljöerna att jobba med. Just den aspekten har förbättrats rejält i senare versioner av UE4 samt i UE5.

Nu har jag programmerat betydligt mer i C och C++ än C#. Men med C# är mycket konvertering, minneshantering (garbage collection) m.m. inkluderat i språket. Håller med dig om att man antagligen får effektivare kod i C++ speciellt när projekten växer.
Kanske beror det också på vilken utvecklingsmiljö jag testat. Där man t.ex. i visualstudio får massa förslag genom . efter en klass, variabel m.m. Inkluderar man motsvarande saker i C++ får man ju det även där, bara det att man just måste göra det och veta vad man ska inkludera och det kanske inte är så lätt om man är ny. När jag programmerat C# har jag varit överraskad av just denna enkelhet med typ-konverteringar m.m. Det man vill göra finns ofta en . bort medans i C++ måste man ha koll var det kan tänkas finnas eller programmera denna funktionalitet själv.

Permalänk
Medlem

@zonezoon: C++ är ett mycket större språk än C (särskilt med standardbiblioteket inräknat), men det finns inget som tvingar dig att använda t.ex. OOP i C++. Kollar du på t.ex. learncpp så börjar de inte med OOP förrän i kapitel 12, och har då redan gått igenom i princip hela C.

Permalänk
Medlem

Ja, C är enklare än C++. Men du måste göra mycket mer "för hand" i C. Det saknas en vettig stränghantering och du måste använda explicit minneshantering för saker som du är van att ha lättillgängliga i Python (listor, tupler, set, dictionaries). Det finns i C++. Steget från Python till C är mycket längre än till C++ (11 och nyare).

Permalänk
Datavetare
Skrivet av zonezoon:

Galet bra respons från er alla! Efter jag har läst varje svar och förklaringar som ni har skrivit så känner jag mig som en riktig nybörjare… 🤣 Jag försöker hänga med och förstå vad ni menar men ibland tappar ni mig. Så som jag har uppfattat det så är C++ ett gigantiskt språk och kan ses som väldigt tungt att börja med. Jag vet inte om jag nämnde det tidigare men den väldigt lilla programmering jag gör ser jag enbart som en hobby. Jag vet inte själv riktigt vad jag vill göra inom programmering och jag vet inte vad man kan göra, så jag tänkte att spel kan väll vara roligt. Rätta mig om jag har fel, men C verkar vara enklare än C++ eftersom C inte har OOP. Jag kan mer än gärna börja med C om det skulle vara så, som sagt - allt det här är så fruktansvärt nytt för mig så jag har väldigt lite koll på vad som gäller och inte men hyfsat roligt tycker jag det är i alla fall.

För att ge dig bra svar tror jag en sak du berör ovan är kritiskt att få ett svar på:

  1. Är huvudmålet att lära dig C++, d.v.s. att programmera spel är mer ett exempel på vad du kanske vill göra?

  2. Eller är huvudmålet att börja skriva spel, att lära sig C++ verkade i den kontexten väldigt användbart?

Om 1.
Är det verkligen C++ du vill lära dig eller vill du lära dig ett språk som ger "total kontroll"?
Här finns ju andra alternativ som C, Rust och, om du jobbar på Mac/iOS, Swift

Om det verkligen är C++ programmering du vill lära dig så ska du absolut börja med någon av de lysande exempel på böcker som nämnts i tråden.

Om 2.
Skulle säga då du redan kan programmera i Python kan det vara roligare att först börja sätta dig in i någon spelmotor, går att göra rätt roliga saker relativt snabbt. Det kommer mer vara svårigheten att förstå själva miljön än programmeringen i sig som kommer vara största initiala hinder.

Med Blueprint i UE4/5 och dina kunskaper från Python kan du komma igång med "programmeringen" direkt i den miljön. Går sedan att gradvis lyfta ut del för del i C++ om det krävs mer umph!

Säger inte att detta är bästa videon som finns, men kan vara kul att se hur man använder Blueprint i UE5

Permalänk
Medlem
Skrivet av Yoshman:

För att ge dig bra svar tror jag en sak du berör ovan är kritiskt att få ett svar på:

  1. Är huvudmålet att lära dig C++, d.v.s. att programmera spel är mer ett exempel på vad du kanske vill göra?

  2. Eller är huvudmålet att börja skriva spel, att lära sig C++ verkade i den kontexten väldigt användbart?

Om 1.
Är det verkligen C++ du vill lära dig eller vill du lära dig ett språk som ger "total kontroll"?
Här finns ju andra alternativ som C, Rust och, om du jobbar på Mac/iOS, Swift

Om det verkligen är C++ programmering du vill lära dig så ska du absolut börja med någon av de lysande exempel på böcker som nämnts i tråden.

Om 2.
Skulle säga då du redan kan programmera i Python kan det vara roligare att först börja sätta dig in i någon spelmotor, går att göra rätt roliga saker relativt snabbt. Det kommer mer vara svårigheten att förstå själva miljön än programmeringen i sig som kommer vara största initiala hinder.

Med Blueprint i UE4/5 och dina kunskaper från Python kan du komma igång med "programmeringen" direkt i den miljön. Går sedan att gradvis lyfta ut del för del i C++ om det krävs mer umph!

Säger inte att detta är bästa videon som finns, men kan vara kul att se hur man använder Blueprint i UE5
https://www.youtube.com/watch?v=bY6Nl-OEhSo

Mycket bra fråga!
Mitt huvudmål var inte att börja skriva spel och att C++ verkade i den kontexten väldigt användbart. Jag har nog aldrig haft något huvudmål, utan mer en fundering på vad finns det att göra nu? Eftersom jag har spelat hela mitt liv så kom spel upp som en tanke. Jag började googla lite och uppfattade att C++ var språket man använde sig utav, därav skapade jag denna tråd. Jag tycker även att ”säkerhet” verkar intressant. Att utveckla ett system eller liknande för att förhindra hackers att ta sig in. Där har jag definitivt ingen erfarenhet, men det verkar intressant.

Jag hoppas att du förstår vad jag menar. Jag vet egentligen inte vad jag vill med programmering, jag tyckte bara att det var intressant att få labba lite med Python.

Permalänk
Medlem

Kollade in hemsidan learncpp.com och läste även lite recensioner om sidan och många utav dom var positiva. Jag känner att jag vill lära mig antingen C eller C++! Antingen C genom ”Head First C” eller C++ via någon bok eller alternativt learncpp.com som också är gratis.

Permalänk
Medlem

Jag kan också rekommendera C++ Primer och Cherno för att sedan fortsätta med någon bok om t.ex. design pattern eftersom programmering är så mycket mer än bara syntax, minneshantering och det inkluderade biblioteket. Samtidigt är jag biased eftersom det var så jag lärde mig och det är möjligt att det finns bättre böcker.

I övrigt så tycker jag att sidodiskussionen faktiskt är viktigare. Vill du bli C++ programmerare eller skapa spel? Det ena utesluter inte det andra men spelutveckling är så mycket mer än bara språket. Vimlark på Twitch/YouTube sitter i Construct 3 vars logik består av flödesscheman istället för kod. Personligen så skulle jag inte rekommendera Construct 3 men titta på Godot med GDScript som är väldigt likt Python eller Unity med C# som länge varit det solklara valet om man vill syssla med 2D eller mobilspel. De hävdar själva att mer än 50% av nya mobilspel är utvecklade i Unity och en delorsak utöver dess kompatibilitet är sannolikt deras stöd för att tjäna pengar genom reklam och köp inne i spelet. Unreal Engine använder sig av C++ eller blueprint men mitt intryck är att det inte lämpar sig särskilt väl för mindre 2D-spel.

Nu menar jag inte att C++ är fel utan min poäng är att språket bara är ett verktyg. Fundera på vad du vill uppnå. Att börja med Unity och spotta ut 15-20 spel på ett år samtidigt som man lär sig C# och deltar i game jams med en vän ger helt andra kunskaper än om man lär sig CMake, filhantering, minneshantering och algoritmoptimering i C++.

Permalänk
Entusiast

Om du vill lära dig UE med C++ så rekommenderar jag videon från Tom Looman. Han finns bl.a. i Udemy https://www.udemy.com/course/unrealengine-cpp/
Du behöver inte återskapa en spelmotor om det redan finns flera bra tillgängliga. Dessutom kan det vara bra att lära sig om UE, Unity och ev. andra motorer om hur de är uppbyggda, (filosofiskt)strukturerade m.m. innan du sätter dig in i att skapa en egen motor.
Men visst kan det vara kul att lära sig göra en egen spelmotor givetvis.

Om du väljer spelprogrammering med UE så är det bra att känna till att UEs C++ är lite annorlunda än "vanlig C++"; Helt enkelt är det bara att direkt hoppa in i Toms kurser efter att ha lärt dig grundläggande om C++ (variabler, klasser, pekare/referenser o.s.v.).

Precis som Yoshman har sagt ett par gånger nu, lära dig UE via Blueprint är ett fantastiskt tillvägagångssätt. Du kan lyfta fram dina kunskaper från BP om UE, hur UE är uppbyggd, var funktionerna finns och vad de heter till din C++ kod.
Du kan dessutom dubbelklicka på en BP nod i UE editorn och öppna upp C++ koden för den i din IDE för att se hur den ser ut.
UE har dessutom "nativization" kompileringsfunktion som gör BP ännu mera kraftfulla prestandamässigt. (Tar lite extra kompilerings tid vid build eller "launch as standalone")

För allt annat där antingen BP funktioner saknas eller att du vill ha mer prestanda ur en funktion (UE har bra performance profilers) så kan du superlätt skapa dina egna BP noder som kör egen C++ kod.

Jag brukar köra allt på BP tills jag vill ha mer prestanda eller känner att det skulle vara mer strukturerad i C++ form. (eller att en funktion helt enkelt saknas i BP form). Brukar även bygga upp i BP när det görs prototyp-funktioner.

Kan även starkt rekommendera gratis tutorials från Bry https://www.youtube.com/c/brynertoma om du vill lära dig om network replication (multi-player, client/server med UE)
Annars finns även Epics egna tutorials från Zak Parrish "BP communications" som är en fin klassiker

Permalänk
Medlem
Skrivet av HappyPie:

Om du vill lära dig UE med C++ så rekommenderar jag videon från Tom Looman. Han finns bl.a. i Udemy https://www.udemy.com/course/unrealengine-cpp/
Du behöver inte återskapa en spelmotor om det redan finns flera bra tillgängliga. Dessutom kan det vara bra att lära sig om UE, Unity och ev. andra motorer om hur de är uppbyggda, (filosofiskt)strukturerade m.m. innan du sätter dig in i att skapa en egen motor.
Men visst kan det vara kul att lära sig göra en egen spelmotor givetvis.

Om du väljer spelprogrammering med UE så är det bra att känna till att UEs C++ är lite annorlunda än "vanlig C++"; Helt enkelt är det bara att direkt hoppa in i Toms kurser efter att ha lärt dig grundläggande om C++ (variabler, klasser, pekare/referenser o.s.v.).

Precis som Yoshman har sagt ett par gånger nu, lära dig UE via Blueprint är ett fantastiskt tillvägagångssätt. Du kan lyfta fram dina kunskaper från BP om UE, hur UE är uppbyggd, var funktionerna finns och vad de heter till din C++ kod.
Du kan dessutom dubbelklicka på en BP nod i UE editorn och öppna upp C++ koden för den i din IDE för att se hur den ser ut.
UE har dessutom "nativization" kompileringsfunktion som gör BP ännu mera kraftfulla prestandamässigt. (Tar lite extra kompilerings tid vid build eller "launch as standalone")

För allt annat där antingen BP funktioner saknas eller att du vill ha mer prestanda ur en funktion (UE har bra performance profilers) så kan du superlätt skapa dina egna BP noder som kör egen C++ kod.

Jag brukar köra allt på BP tills jag vill ha mer prestanda eller känner att det skulle vara mer strukturerad i C++ form. (eller att en funktion helt enkelt saknas i BP form). Brukar även bygga upp i BP när det görs prototyp-funktioner.

Kan även starkt rekommendera gratis tutorials från Bry https://www.youtube.com/c/brynertoma om du vill lära dig om network replication (multi-player, client/server med UE)
Annars finns även Epics egna tutorials från Zak Parrish "BP communications" som är en fin klassiker

Har börjat läsa på om BP och UE efter Yoshmans rekommendationer. Ska definitivt kolla in dina länkar med. Tack för ditt inlägg!

Permalänk
Medlem

Det lutar mot C++. Läsa på om grunderna i C++ och sen kika in BP och UE. Det ser spännande ut!