C# framtiden inom spelprogrammering?

Huvudproblemet med C++ är att språket har massor av extra detaljer och regler som inte är helt uppenbara, vilket också är en av orsakerna till att man fortfarande skriver OS-kärnor i C. C gör uppenbarligen vad koden säger. C++ är mycket mindre uppenbart (om man nu inte verkligen är en C++ guru). Exceptions, polymorfism (virtuella funktioner) och "för mycket OOP" tenderar också att vara skadligt, prestanda-mässigt sett.

Att byta över till C helt för dem tidskritiska delrana är oftast inte nödvändigt. Istället brukar man helt enkelt skriva de facto C-kod i C++ för sådana delar (eller rättare sagt, man stoppar in allt i ett fåtal icke-ärvda, icke-ärvande klasser) alternativt använder sig kraftigt av compile-time polymorfism (i.e. template metaprogrammering).

Det är värt att observera att många C++ kompilatorer egentligen är C kompilatorer med en front-end som konverterar C++ kod till C kod (t.ex. mixar om namnen på funktionerna).

Jasså? Angående kernel utveckling, jag har hört att C++ har så mycket bibliotek (t.ex. STL) och mycket overhead att du vill slippa allt sånt när du programmerar bare-metal som kernel utvecklare. Och skalar du bort bort allting med mycket barlast i C++ så återstår något som liknar C. Då är det lika bra att köra C rakt av.

Angående C++ kompilatorer som gör allt till C, så har jag hört att det gällde förrut för längesen. Numera sker inte det. Dagens C++ kompilatorer funkar som vanligt.

"... man fortfarande skriver OS-kärnor i C."

C++ i sig har egentligen ingen (märkbar) overhead jämfört med C, om man glatt använder sig av templates och kompilerings-tids polymorfism (och dylikt) istället för vanlig dynamisk polymorfism.

Men det finns egentligen ingen tvekan om att C är kod-stils mässigt sett mer robust än C++.

C++ har:

- Ett helt isberg med finstila regler. Folk som har jobbat med C i 10+ år vet oftast det mesta om språket. Folk som har jobbat med C++ i 10+ år kan lätt "knäckas" med "finstila frågor" (t.ex. sådana från http://www.gotw.ca/gotw/ ).

- Mindre väldefinerade namn-scheman och dylikt i kompilerade enheter (i.e. varför det är "extern C" men inte "extern C++" ). Att länka C++ kod kompilerad med lite olika kompilatorer är inte en god idé alls. Statiska objekt bör inte användas överhuvudtaget. Med templates så vet man oftast dessutom inte var koden är i för minnes-sida vilket kan få oanade konsekvenser i kernel-läge (t.ex. om man går in i ett läge där minne inte längre kan swappas från hårddisken så vill man med säkerhet veta att dessa minnessidor är i RAM-et redan).

- Undantag. STL och C++ i allmänhet föredrar RAII och användning av exceptions för att signalera fel. Detta kan speciellt i kernel-fallen vara en paradigm som är mycket svårare/omöjlig att göra robust än C-stilens "returnera fel-kod"... för att inte nämna ibland oacceptabla prestanda-förluster med stack-unwinding.

I slutändan är det helt enkelt inte värt att koda i C++ då man ändå måste "artificiellt" lägga på massor av extra egna kodnings-regler (som lätt kan glömmas och få kernel-kodsnutten att crasha... ibland).

I strikt mening så stämmer det att dagens C++ kompilatorer inte gör en ren översättning till C längre, utan konverterar både C och C++ kod till ett "mellan stegs intern representation" (varken C eller C++) som sedan optimiseras och "riktigt" kompileras till binärkod.