Er det rimeligt at skrive en spilmotor i C? [lukket]

Ville det imidlertid være urimeligt at skrive en hel spilmotor i dag i dag?

Det er rimeligt, men spørgsmålet er, hvad køber det dig? Du har sandsynligvis ikke brug for den ekstreme bærbarhed, som C tilbyder, og det er en skam at opgive alle de funktioner, som C ++ tilbyder, medmindre du virkelig er filosofisk imod det.

Hvad er, hvis nogen, nogle fordele, som C har i forhold til C ++?

Bedre kompileringstid?

Hvorfor ville nogen stille vil du gerne bruge C over C ++?

Jeg synes, det mest er et æstetisk valg. Mange mennesker kan lide C, fordi det er simpelt og minimalt og føles rent. C ++ har mange gode funktioner (navneområder alene gør det værd at bruge), men det er også stort og rodet.

Kommentarer

• Indtil Id Tech 4
• @Josh: Lettere at debug !? C-programmer er notorisk vanskelige at debugge, hovedsageligt på grund af pekere og hukommelsesadministration. C ++ programmer (når du bruger ægte C ++ programmeringsidiomer, som har tendens til at undgå pekere og hukommelsesadministration når det er muligt) er flere størrelsesordener lettere at debugge.
• C kan forstås af bare dødelige. C ++ ser ud til at have mange funktioner og edge cases, erfarne programmører lærer om selv efter et årti med at bruge det hver dag til at leve.
• C ++ er et stort sprog, men det ' s frygtindgydende omdømme spredes hovedsageligt af mennesker, der ' lige har læst horrorhistorier og ikke har taget ' tid til at lære det . Der er meget at lære, men du får en masse værdi til gengæld for det. C ++ giver dig mulighed for at udtrykke mange ting, som C simpelthen kan ' t.
• @ BlueRaja-DannyPflughoeft #define malloc(x) my_malloc(x) #define free(x) my_free(x), og du fejler nu hukommelsen. Med C ++ ved du aldrig, hvad der tildeles hvornår, fordi der er så mange måder at allokere hukommelse på (ny, malloc, klassekonstruktører osv.)

Jeg har arbejdet meget med en ren-C spilmotor, der har leveret flere produkter, så det er absolut muligt. Her er min personlige erfaring med at arbejde i begge C vs C ++ motorer:

1. Brug af pure-C strukturer giver dig mulighed for at drage fordel af viden om tilpasning af strukturer, og du kan derefter bruge denne information for at opbygge dit objekt-persistens- og serialiseringslag.Motoren, jeg arbejdede med, havde nogle enkle header-parsere, der automatisk ville skabe disse metadata om strukturer, og det gjorde visse typer datahandlinger trivielle. Parsing af vilkårlige C ++ -hovedfiler er i det væsentlige umuligt, og så snart når du tilføjer arv og virtuelle funktioner, mister du evnen til at vide nøjagtigt, hvor ting er i hukommelsen
2. Kompileringstiden er betydeligt kortere, fordi du kan holde dine headerfiler meget kompakte og drage fordel af fremadrettede erklæringer om strukturer.
3. Fejlfinding kan forbedres, fordi det uden brug af skabeloner og arv er meget let at finde ud af, hvad et bestemt objekt er, og hvad det laver.

Alle disse fordele kunne også lige så let opnås ved hjælp af begrænset c ++ – kode, der afstår fra at bruge skabeloner og arv på serielle objekter, men det var CTOs beslutning, at det ville være lettere for at håndhæve enkelheden, hvis de mere forvirrende elementer i C ++ ikke var tilgængelige.

Personligt synes jeg, dette var lidt ekstremt, da jeg virkelig savnede muligheden for tilstrækkeligt at erklære variabler i sløjfer og de mange helt legitime anvendelser til arv. Men det kostede os virkelig ikke meget produktivitet til sidst alt taget i betragtning

Kommentarer

• Der ' er virkelig intet, der forhindrer dig i at implementere arv i C. Og hvis du bruger C99, kan du erklære variabler for sløjfer.
• Går uenig med punkt 3. Det ' er lige så let at skrive rodet, svært at fejle kode i C som det er i C ++. Bedre fejlfinding er ikke ' t noget, der ligger i C-sproget.
• Selv ren kode kan være sværere at forstå i C ++ – med overbelastning, skabeloner, virtuelle funktioner og undtagelser, det ' er meget sværere at se med det samme nøjagtigt, hvad den aktuelle kontrolflow vil være.
• @Dan: Simpelthen ved at have flere ting er C ++ sværere at debugge. Du kan selvfølgelig begrænse dig fra at bruge noget af det, i hvilket tilfælde det bliver lige så let at debugge som C – fordi det bliver C.
• Mindre ting er faktisk grunden til, at jeg kan lide C. F.eks. i CI kan bare kopiere bits og bytes rundt med en memcpy til noget, fordi typesystemet ikke tillader ' t ting som kopi-ctors og dtors . Jeg kan skrive kode vel vidende, at jeg ikke vil ' behøver at rulle bivirkninger tilbage på næsten en hvilken som helst kode kode, da jeg ' t implicit forlade en funktion, medmindre jeg udtrykkeligt vender tilbage fra den; der er ingen undtagelser, der kastes. Alt dette gør skrivning af datastrukturer så meget lettere – i C ++ er det bare meget tidskrævende at skrive en standardkompatibel vector, især hvis du vil gøre det …

Jeg omskriver en 2D-spilmotor skrevet i C ++ og Lua til C og Lua. Indtil videre har oplevelsen været ganske god. Selvfølgelig ender det med at udføre vektor- og matrixoperationer ikke så godt ud i C. Men bortset fra det har jeg fundet oplevelsen ret forfriskende efter at have brugt 10+ år som C ++ -udvikler.

C har en række fordele i forhold til C ++:

1. Compileren sørger for, at der ikke køres kode ved statisk initialiseringstid. Det gør det helt sikkert at statisk allokere globale data som strenge, der bruges som nøgler, fx
2. Gennemsigtighed. I C-tildeling eller tildeling eller definition af en variabel vil ikke køre belastning af kode. C ++ genererer automatisk kopikonstruktører til dig, så du har mindre kontrol over, hvad der bliver udført, når du udfører en opgave.
3. En masse fejlsøgning kan være lettere at være på grund af manglende funktionsnavne
4. Det er normalt okay at bruge memcpy i C, men det vil let skabe problemer i C ++, fordi kopikonstruktører ikke køres. tha t memcpy er meget hurtigere end std :: kopi der betyder noget.

Bortset fra det er der en række fordele ved at komme ind i C-tankegangen. I C ++ finder jeg ofte mig selv at gøre tingene lidt overgeneraliserede og abstrakte. I C skærer jeg normalt ting ud som get-set-metoder og forudloker ofte arrays med fast størrelse i stedet for at bruge dynamiske arrays. Ofte ender jeg med kortere og lettere debugged kode i C. Datastrukturerne er normalt fladere og lettere at se i en debugger.

For at være retfærdig ville jeg aldrig lave en app udelukkende i C. Årsagen det virker, at jeg kombinerer det med et højere sprog som Lua, som kan supplere C meget godt, hvis C ikke er så stærk.

Id-software skriver de fleste af deres motorer i CI-tro, du kan se på Tilbage til slot Wolfenstein , som blev skrevet i C.

Jeg skrev om noget af min oplevelse på skalerbarhed af C vs C ++ og Ulemper ved STL-vektor sammenlignet med almindelige arrays.

Kommentarer

• FYI, i hvert tilfælde at jeg ' har kontrolleret (hvilket er, tror jeg darwin gcc og vc2008), std :: copy vil kompiler bare til et opkald til memcpy, hvis begge typer er POD.
• Også, RE: STL-vektor vs almindelige arrays, hvorfor ikke bruge de pæne dele af vecto r og brug normale C-markører i stedet for iteratorer, hvis du ikke kan lide '? Du kan bare gøre & myvector [N].Det ' er som det bedste fra begge verdener, forudsat at din C-kode tildeler hukommelse på samme måde. Eller se BOOST_FOREACH, hvis der er sløjfer. Gør det endnu enklere end C.
• Tak for tipet om std :: copy memcpy. Jeg vidste det ikke '. Da Alexandrescu behandlede dette for nogle år siden, var det ikke tilfældet. Om C ++ iteratorer. Det handler primært om filosofien, jeg prøver at programmere, hvordan C ++ var beregnet til at være program både for de mennesker, jeg arbejder med, og for at drage fordel af C ++ – funktioner. Det blev hovedsageligt lavet for at påpege, at nogle C ++ forbedringer som STL-containere ikke altid er bedre end at gøre det på den gamle C-måde.

Jeg don ” tror ikke nogen bruger C udelukkende i disse dage, det blandes normalt sammen med et højere sprog.

Programmering i C har nogle fordele i forhold til f.eks. programmering i C ++. C ++ kan gøre mange ting under emhætten, der er usynlige for brugeren, hvilket kan skade ydeevnen, hvis du ikke er forsigtig. C ++ kan også være forfærdelig, når det kommer til cache-brug, hvilket igen kan skade din præstation.

Så det kan medføre nogle fordele ved at skrive de ydeevnekritiske dele af et spil på en C-lignende måde snarere end på en traditionel C ++ måde. Jeg har aldrig hørt om nogen, der i de senere år faktisk har skrevet et helt spil i C. Dog.

På nogle platforme, som f.eks. iPhone, kan brug af C ++ øge din eksekverbare størrelse med et bestemt stykke kilobyte (jeg glemte hvordan meget, undskyld), hvilket er en grund til, at nogle iPhone-udviklere vælger at skrive deres kode i en blanding af C og Objective-C.