Lära sig C++, böcker

Kanske därför att ISO-C11 och ISO-C++11 är de enda språken som än så länge lyckats abstrahera de fundamentalt viktiga delarna för att skriva korrekta och effektiva program som använder flera CPU-kärnor?

Java är väl närmaste konkurrent på den punkten, men det är inte alls lika generellt och på en del sätt också svårare att använda.

Jag har redan förklarat mina anledningar.

Det är väldigt svårt att själv skriva bättre optimerad kod i assembler än vad en C-kompilator presterar. C++ är näst intill lika effektivt som C. Ska man programmera nära hårdvaran finns det inte så många andra alternativ utom assembler då, men med assembler blir inte koden lika portabel. Men assembler är roligt och ökar förståelsen för hur en processor fungerar så det är inte fel att åtminstone prova på det någon gång.

Men nu handlade inte tråden om att ifrågasätta valet att vilja lära sig C++. Brajan ville ha råd om böcker. Jag själv vill också ha svar på den frågan så jag kommer bevaka tråden.

Effektivitet är bara en del av vad jag refererar till. C11 och C++11 har primitiver som inte bara är långt mer effektiva än andra språk, de är mycket lättare att använda för de som skapat dem har äntligen förstått vad vi som skriver program för multicore behöver.

Och nej, C#/.Net suger verkligen på multicore jämfört med Java och är inte ens på banan jämfört med C11 och C++11. Det går definitivt att skriva korrekta program för multicore i C#, men det skalar apa över några enstaka CPU-kärnor.

Edit: Det du skriver om assembler är idag rätt fel. I praktiken kan ingen människa fullt ut hålla alla beroenden som finns i en modern out-of-order CPU för att lyckas skriva assembler som är mer effektiv än den assembler som skapas av en kompilator genererad från en riktigt bra C-programmerare. Faktum är att C11 och C++11 innehåller just saker som gör det möjligt att uttrycka vad man vill optimera för utan att man alls måste begripa saker som minneskonsistensmodell, out-of-order djup och vilka assembler-instruktioner som är mer effektiva på just den CPU-modell man kör på.

Finns saker som språket C inte kan uttrycka på ett sätt så man kan generera optimal SSE/AVX. Finns flera lösningar på det problemet, endera skriver man den koden i något som OpenCL eller liknande, använder ett färdigskrivet bibliotek eller så kan man i de flesta kompilatorer komma åt SSE/AVX-instruktioner direkt från C (kompilator gör däremot registerallokering och ser till att data kommer till/från register på ett optimalt sätt, så det är inte samma sak som att skriva assembler) via s.k. intrinsics

Helt sant, C++11 och senare är på många sätt en annat språk än tidigare C++ versioner. Herb Sutter belyser flera av skillnaderna mellan "gamla" C++ och "nya" C++ i denna video: Not Your Father's C++

Edit: då jag redan listat ett klipp med Herb Sutter och C++11 så är det kanske lika bra att lista denna mastodontsession om C++ atomic<>, är två klipp på ca en timme var och dessa är riktigt intressanta om man vill hålla på med multitrådning i C++11.
Atomic weapons part 1
Atomic weapons part 2

atomic<> är bara en väldigt liten del av allt man lagt till för multitrådning i C++, men det är en av punkterna där C++ (och C11 har liknande saker) skiljer sig (till det bättre) från andra språk. Faktum är att både C och C++ totalt saknade något alls i standaren för hur saker beter sig på multicore CPUer innan 2011 års standard. Notera också att C och C++ är separata språk med separat standard, dessa språk har divergerat en del så C är inte längre (sedan 1999) en delmängd av C++.

Här är en sammanställning av en presentation Sutter jag kring när C++ är ett bättre val än det han kallar "Coffee-based languages" (t.ex. C# och Java). Bl.a. nämner han att MS försök med att göra ett OS som i grunden var byggd på .Net totalt havererade (projektet startades i princip om och ledde till Vista ca 3 år senare än ursprungsplanen).
"However, as the OS was being developed, they realized that managed languages didn’t have the performance, deployability or serviceability (among others) required to develop an Operating System. That’s why Windows nowadays is all C and C++ and will probably stay that way."

Slänger in samma länk som senast en liknande tråd dök upp:

Att säga att C++ inte är snabbare än assembler är ett rätt meningslöst påstående. Visst, finns garanterat någon kombination av assemblerinstruktioner som kan lösa vissa fall bättre än den assembler som genereras från C++ av en kompilator. Men tar du tusen programmerare på måfå skulle jag vara ytterst imponerad mer än en/två stycken överhuvudtaget lyckas presterar något som är snabbare än det kompilatorn gör även om de får använda tio gånger så mycket tid som C++ programmeraren. En förkrossande majoritet av programmerarna kommer producera något som är långsammare än kompilatorn oavsett hur lång tid man ger dem. Så nej, rent praktiskt är C och C++ lika snabbt som assembler då dagens CPUer har så komplexa beroenden att de vida överstiger de ca 7 saker människor kan hålla i sin "L1-cache". En kompilator har inte alls samma begränsning på den punkten.

Kliver man in på multicore optimeringar är det långt viktigare att få till saker som vilket data som delar och inte delar cache-line med annan data, hur access till data är samordnat, m.m. Finns inget i assembler som gör detta mer effektivt än i C och C++, snarare att det är långt mer komplicerat då mycket av detta kan kompilatorer ordna åt dig bara man markerar sitt data på rätt sätt (tyvärr krävs ibland kompilatorspecifika attribut).

Att skriva assembler är inte så tidsödande som vissa verkar tro, har faktiskt skrivit hela spel på Amiga helt i assembler. Däremot är det ofta svårt att modifiera saker i efterhand då man måste helt förstå en människas ad-hoc användning av CPU-register och vad de representerar. Det är ett write-only language och det tar definitivt längre tid än att skriva i t.ex. C++.

Angående Microsoft och C++ så verkar de mycket riktigt hårdsatsa på detta språk igen. Finns videor på channel 9 (borde vara från 2011-2012), i serien som kallas "going native", där man pratar om att MS själva kom till insikten att hela deras företag är byggt på C++ men man hade under lång tid behandlat MSVC++ ganska styvmoderligt. Nu gör man en hårdsatsning på C++ och enligt Herb Sutter (som är både MS anställd och är/har varit ordförande i ISO C++ kommittén) ska man så långt som möjligt använda ISO C++ i stället för egna påhitt. Tyvärr är man inte helt hemma på den punkten då CX som används av WinRT (APIet inte Windows på ARM) är en icke-standardutökning.

Rent generellt så finns det inget i modern C++ som hindrar en att skriva mer eller mindre exakt samma kod som i C#, så utvecklingstiden i dessa språk är ungefär den samma förutsatt att man har tillgång till ungefär samma biblioteksfunktioner och att prestanda är irrelevant (annars vinner C++ på W.O.).

Forskning visar ju att om man skriver rubbet själv så är just val av språk rätt liten roll, bl.a. visade en rapport nyligen att ca 80% av alla buggar utvecklar skriver är buggar i logiken vilket gör val av språk helt irrelevant. Personligen tycker jag både C++ och C# är alldeles för komplicerade språk (hur många professionella C++/C# programmerare kan verkligen hela språkdefinitionen?) och föredrar språk där ett av huvudkriterierna är enkelhet, t.ex. Go, Clojure men även C pass in ok här. Däremot ser det definitivt ut som C++ kommer kliva upp i "viktighetsgrad" om man jobbar med Microsoftprodukter tack vare deras hårdsatsning på C++ och "native"-utveckling.

För att tillföra något vettigt till det TS frågar också: mitt tips är att titta på informationen hos cplusplus.com. Medan du läser böcker kan det vara väldigt värdefullt att titta på de standardfunktioner du ser i böckerna. Läser du t.ex. om std::all_of i <algorithm> så gå dit, läs om funktionen och framförallt titta igenom de exempel de har och se till att du förstår vad exemplen gör. Finns också en tutorial som är väl värd att gå igenom när du greppat grunderna, d.v.s. i alla fall kommit igenom en C++ bok.

Bytte användarnamn av två skäl, "virtual void" var lite långt och namn med två ord är lite drygt för folk att referera till. Sedan heter min hund (som är en dvärgschnauzer precis som hunden i avataren) Yoshi och kallas ibland för Yoshman.

Att använda C-bibliotek från C++ kräver ingenting i normalfallet då i princip alla som jobbar med C har som del av kodstandard att lägga in

#ifdef __cplusplus
extern "C" {
#endif

// exporterade funktioner och typer

#ifdef __cplusplus
}
#endif

Skulle man stöta på ett C-bibliotek som mot förmodan saknar detta går det att lösa i sin egen C++ fil genom att göra detta

extern "C" {
#include <some_c_library.h>
}

C++ bibliotek som Qt och boost är i praktiken helt oanvändbara från C då de bygger på finesser som inte existerar i C. Anledningen till att så få bibliotek har C++ gränssnitt beror främst på två saker

• C-bibliotek kan användas från C++, C++ bibliotek kan inte används från C. C är ett större språk än C++ räknat i antalet projekt och programmerare så inget man vill ignorerar

• C-bibliotek är standardiserade ändå ner på binärnivå vilket betyder att ett bibliotek kan utvecklas med en kompilator och garanterat fungera med en annan kompilator. C++ är bara standardiserat på kodnivå, inte på binärnivå, så ett bibliotek som är kompilerat med säg g++ kanske inte fungerar i ett program som byggs med MSVC++. En stor anledning till att Microsoft har sin CX extension i WinRT kommer från att de måste ha bibliotek där även binären har en hår specifikation, CX är i stort sett en ny version av COM+ (som kommer från COM som kommer från OLE).

Är just att folk jämför C#/.Net med C++/STL som får många att dra slutsatsen att det går mycket fortare att skriva program i C#. Rätt jämförelse här är endera C# endast med CLI standard libraries alt. C++ med något som Qt eller WinRT. Tittar man på rent språkliga konstruktioner finns det egentligen väldigt lite i C# som inte har en ett-till-ett mappning i C++11, även saker som LINQ finns som bibliotekstillägg i C++ idag (fast med väldigt mycket bättre prestanda, men typiskt inte fullt lika mycket finesser).

Däremot har C++ möjlighet till s.k. template metaprogramming som gör det möjligt att åstadkomma väldigt extrema prestandaoptimeringar som är väldigt rättfram att använda för 3:e-part. Att skriva template libraries är däremot man ska lämna till folk som är C++-experter då det är väldigt många hål att kliva i. Stora delar av boost och även C++ standardbibliotek är just template-bibliotek.

Ett exempel som på ytan ser rätt lika ut i t.ex. C++ och C# men runtime-mässigt beter sig väldigt olika är tuples<>. Antag att man har en typ som håller en sträng och ett heltal

// C#
var t = Tuple.Create("Kalle", 20);
Console.WriteLine("name={0}, age={1}", t.Item1, t.Item2);

// C++
auto t = make_tuple("Kalle", 20);
cout << "name=" << get<0>(t) << ", age=" << get<1>(t) << endl;

Kollar man genererad kod för detta kommer man ser att t.Item1 är ett anrop via en funktionspekare (väldigt dyrt, framförallt på enklare CPUer som Atom och ARM) medan det överhuvudtaget inte blir ett funktionsanrop alls i C++ då "anropet" körs i kompilator som då inser att man direkt kan stoppa in adressen till respektive datafält (en optimering som .Net överhuvudtaget inte gör, Java kan teoretiskt utföra denna optimering i runtime under vissa lägen om det är en JVM med re-JIT stöd).

Väldigt mycket som gör C++ snabbare än andra språk är att saker som ser ut som funktionsanrop endera blir direkta anrop (som är minst dubbelt så snabbas som indirekta anrop som anrop via funktionspekare är) eller inga anrop alls då kompilatorn gör om det till direkta datareferenser via template-magi. Programmeraren behöver inte bry sig om detta, det händer automatiskt och är egentligen ingen magi då det är en del av språkdefinitionen för C++ att göra dessa saker.

Problemet med det rådet är att, som bl.a. Herb Sutter belyser i "Not Your Fathers C++" som jag länkade ovan, i C++11 och senare väljer man i många ganska grundläggande delar andra lösningar än i "klassisk" C++.

Bara för att ta en sak så skulle en "kassisk" C++ programmerare få spader om hen såg detta

vector<T> makeManyTs()
{
...
}

i stället skulle hen vilja ha detta

void makeManyTs(vector<T> &result)
{
...
}

Men i C++11 är det första garanterat att vara billigt (via move-semanic och rvalue references) och det är därför det rekommenderade sättet att skriva sådan kod.

Så lär man sig C++ finns ingen anledning att inte direkt lära sig "nya" C++, d.v.s. C++11. Fokus i C++14/17 är mest utökning av standardbilioteket och lite finputsning på syntax, inget kommer nära de kraftiga förändringarna som C++11 införde.