Är det rimligt att skriva en spelmotor i C? [stängd]

Skulle det dock vara orimligt att skriva en hel spelmotor idag?

Det är rimligt, men frågan är vad köper den dig? Du behöver troligen inte den extrema portabiliteten som C erbjuder, och det är synd att ge upp alla funktioner som C ++ erbjuder om du inte riktigt är filosofiskt emot det.

Vilka är, om några, några fördelar som C har över C ++?

Bättre sammanställningstid?

Varför skulle någon posera vill du använda C över C ++?

Jag tycker att det mest är ett estetiskt val. Många tycker om C eftersom det är enkelt och minimalt och känns rent. C ++ har många fina funktioner (namnrum ensam gör det värt att använda), men det är också stort och rörigt.

Kommentarer

• Fram till Id Tech 4
• @Josh: Lättare att felsöka !? C-program är notoriskt svåra att felsöka, till stor del på grund av pekare och minneshantering. C ++ – program (när du använder sanna C ++ – programmeringsidiom, som tenderar att undvika pekare och minneshantering när det är möjligt) är flera storleksordningar lättare att felsöka.
• C kan förstås av bara dödliga. C ++ verkar ha många funktioner och edge-fall erfarna programmerare lär sig om även efter ett decennium av att använda det varje dag för att leva.
• C ++ är ett stort språk, men det ' s fruktansvärda rykte sprids mestadels av människor som ' bara har läst skräckhistorier och inte har tagit sig tid att lära sig det ' . Det finns mycket att lära sig, men du får mycket värde i gengäld för det. C ++ låter dig uttrycka många saker som C helt enkelt kan ' t.
• @ BlueRaja-DannyPflughoeft #define malloc(x) my_malloc(x) #define free(x) my_free(x) och du felsöker nu minnet. Med C ++ vet du aldrig vad som kommer att tilldelas när, för det finns så många sätt att fördela minne (nytt, malloc, klasskonstruktörer etc.)

Jag har arbetat mycket med en ren C-spelmotor som har levererat flera produkter, så det är absolut möjligt. Här är min personliga erfarenhet av att arbeta i båda C- och C ++ -motorerna:

1. Med rena C-strukturer kan du dra nytta av kunskap om strukturernas inriktning, och du kan sedan använda denna information för att bygga ditt objekt uthållighet och serialisering lager. Motorn jag arbetade med hade några enkla rubrik parsers som automatiskt skulle skapa denna metadata om strukturer, och det gjorde vissa typer av datahantering trivial. Att analysera godtyckliga C ++ rubrikfiler är i princip omöjligt, och så snart när du lägger till arv och virtuella funktioner förlorar du förmågan att veta exakt var saker finns i minnet
2. Kompileringstiden är betydligt kortare eftersom du kan hålla dina rubrikfiler mycket kompakta och dra nytta av framåtriktade deklarationer av strukturer.
3. Felsökning kan förbättras eftersom det utan användning av mallar och arv är mycket lätt att ta reda på exakt vad ett visst objekt är och vad det gör.

Alla dessa fördelar kunde också uppnås lika enkelt med begränsad c ++ – kod som avstår från att använda mallar och arv på seriella objekt, men det var CTO: s beslut att det skulle bli lättare för att upprätthålla enkelheten om de mer förvirrande elementen i C ++ inte var tillgängliga.

Personligen tycker jag att detta var något extremt, eftersom jag verkligen saknade möjligheten att förnuftigt förklara variabler för loopar och de många helt legitima användningarna för arv. Men det kostade verkligen inte oss mycket produktivitet i slutändan.

Kommentarer

• Det ' är egentligen ingenting som hindrar dig från att implementera arv i C. Och om du använder C99 kan du förklara variabler för loopar.
• Kommer att vara oense med punkt 3. Det ' är lika lätt att skriva rörigt, svårt att felsöka kod i C som det är i C ++. Bättre felsökning är inte ' t något som är inneboende i C-språket.
• Även ren kod kan vara svårare att förstå i C ++ – med överbelastning, mallar, virtuella funktioner och undantag, det ' är mycket svårare att snabbt se exakt vad det faktiska kontrollflödet blir.
• @Dan: helt enkelt genom att ha fler grejer är C ++ svårare att felsöka. Du kan naturligtvis begränsa dig från att använda något av det där, i vilket fall det blir lika lätt att felsöka som C – för det blir C.
• Mindre saker är faktiskt anledningen till att jag gillar C. Till exempel, i CI kan bara kopiera bitar och byte runt med en memcpy för vad som helst eftersom typsystemet ' inte tillåter saker som att kopiera ctors och dtors . Jag kan skriva kod med vetskap om att jag inte kommer att få ' t att få tillbaka biverkningar med nästan vilken kod som helst eftersom jag inte kan ' t implicit lämna en funktion såvida jag inte uttryckligen återvänder från den; det finns inga undantag som kastas. Allt detta gör skrivning av datastrukturer så mycket enklare – i C ++ är det bara tidskrävande att skriva en standardkompatibel vector, speciellt om du vill göra det …

Jag skriver om en 2D-spelmotor skriven i C ++ och Lua till C och Lua. Hittills har upplevelsen varit ganska bra. Självklart slutar det med att göra vektor- och matrisoperationer inte så snygga i C. Men förutom det har jag upplevt upplevelsen ganska uppfriskande efter att ha tillbringat 10+ år som C ++ – utvecklare.

C har ett antal fördelar jämfört med C ++:

1. Kompilatorn ser till att ingen kod körs vid statisk initialiseringstid. Det gör det helt säkert att statiskt allokera globala data som strängar som används som nycklar t.ex.
2. Transparens. I C-tilldelning eller tilldelning eller definiering av en variabel kommer inte att orsaka belastning av kod. C ++ genererar automatiskt kopiekonstruktörer åt dig så att du har mindre kontroll över vad som körs när du gör tilldelning.
3. Mycket felsökning kan vara lättare att göra på grund av att funktionsnamn inte luras
4. Det är vanligtvis okej att använda memcpy i C, men det kommer lätt att orsaka problem i C ++, eftersom kopiekonstruktörer inte körs. tha t memcpy är mycket snabbare än std :: kopiera som betyder något.

Bortsett från det finns det ett antal fördelar med att komma in på C-sättet att tänka. I C ++ befinner jag mig ofta i att göra saker lite övergeneraliserade och abstrakta. I C skär jag vanligtvis saker som get-set-metoder och förlokerar ofta arrays med fast storlek i stället för att använda dynamiska arrays. Ofta slutar jag med kortare och lättare felsökad kod i C. Datastrukturerna är vanligtvis plattare och lättare att se i en felsökare.

För att vara rättvis skulle jag aldrig göra en app enbart i C. Anledningen det fungerar det att jag kombinerar det med ett högre språk som Lua som kan komplettera C mycket bra, om C inte är så stark.

Id-programvara skriver de flesta av deras motorer i CI tror, du kan titta på Återvänd till slottet Wolfenstein som skrevs i C.

Jag skrev om en del av mina erfarenheter på skalbarhet av C vs C ++ och nackdelar med STL-vektor jämfört med vanliga matriser.

Kommentarer

• FYI, i alla fall som jag ' har kontrollerat (vilket är, tror jag, darwin gcc och vc2008), std :: copy kommer kompilera bara till ett samtal till memcpy om båda typerna är POD.
• Dessutom, RE: STL-vektorn vs vanliga matriser, varför inte använda de fina delarna av vecto r och använd normala C-pekare istället för iteratorer om du inte gillar '? Du kan bara göra & myvector [N].Det ' är som det bästa av två världar, förutsatt att din C-kod tilldelar minne på samma sätt. Eller ta del av slingor, kolla in BOOST_FOREACH. Gör det ännu enklare än C.
• Tack för tipset om std :: copy memcpy. Jag visste inte ' det. När Alexandrescu behandlade detta för några år sedan var det inte fallet. Om C ++ iteratorer. Det handlar främst om filosofin, jag försöker programmera hur C ++ var tänkt att vara program både för de människor jag jobbar med och för att dra nytta av C ++ – funktioner. Det gjordes främst för att påpeka att vissa C ++ -förbättringar som STL-behållare inte alltid är bättre än att göra det på det gamla C-sättet.

Jag don ” tror inte att någon använder C exklusivt idag, det blandas vanligtvis tillsammans med ett språk på högre nivå.

Programmering i C har vissa fördelar jämfört med exempelvis programmering i C ++. C ++ kan göra många saker under huven som är osynliga för användaren, vilket kan skada prestanda om du inte är försiktig. C ++ kan också vara hemsk när det gäller cache-användning, vilket återigen kan skada din prestanda.

Så det kan ge vissa fördelar att skriva de prestandakritiska delarna av ett spel på ett C-liknande sätt, snarare än på ett traditionellt C ++-sätt. Jag har har aldrig hört talas om någon, de senaste åren, som faktiskt skrev ett helt spel i C men.

På vissa plattformar, som iPhone, kan C ++ öka din körbara storlek med en viss bit kilobytes (jag glömde hur mycket, förlåt), vilket är anledningen till att vissa iPhone-utvecklare väljer att skriva sin kod i en blandning av C och Objective-C.

Jag ger dig några fler skäl till varför det skulle vara orimligt att skriva en spelmotor i C istället för C ++ idag: STL och BOOST.

Jag kan inte föreställa mig hur det skulle var värt att skriva ännu ett list -implement ntation när du kan lita på kod som fungerar ur rutan (och som du inte behöver skriva!)

Kommentarer

• Har någon stor studio använder faktiskt boost? Även STL-användning är fortfarande under debatt på grund av bärbarhet. Åtminstone för konsolmotorer.
• Personligen <