Timeline for Is it reasonable to write a game engine in C?
Current License: CC BY-SA 2.5
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2020 at 21:17 | comment | added | James M. Lay | Personally, I waste much less time finding and fixing memory issues than I do trying to translate C++ compiler errors. ymmv | |
| Jan 13, 2018 at 8:10 | comment | added | user77245 | @BlueRaja-DannyPflughoeft Of course poorly written C code can be a nightmare to debug with dangling pointers, global variables all over the place, uninitialized variables, insane type casts from one struct to another which require identical alignment, etc. But I'm talking about competently-written C code vs. competently-written C++ code. Between the two I think C has an edge often in ease of debugging (just talking about this and nothing else), and a lot of quality real-world C programs and operating systems are actually very bug-free, arguably just as much or more than C++ counterparts. | |
| Jan 13, 2018 at 8:06 | comment | added | user77245 | @BlueRaja-DannyPflughoeft Compare, say, C libraries out there for a domain where C++ libraries are also available... like image libraries, for example. This might be subjective but if one of them had bugs and I had to debug it for some reason, typically the C libraries are so much easier IMO... starting with the fact that most of them are considerably smaller and generally don't depend on external libs, while the C++ versions are often much larger and can depend on many external libraries. This is still coming from a fan of C++, but I don't think C++ code is easier to debug. | |
| Jan 13, 2018 at 7:58 | comment | added | user77245 | @BlueRaja-DannyPflughoeft ... sometimes you can get tangled up like that, not knowing when/where things are going to be destroyed, when/where side effects occur, in what order things will happen, etc... sometimes all that structure tends to hide away and obscure the most crucial details to debug something, as well as making it harder to fix the problem once you find and recognize it. Debugging is inherently something where you get concerned with low-level details to fix a problem, and there all the abstractions and high-level coding can get in the way. | |
| Jan 13, 2018 at 7:57 | comment | added | user77245 | @BlueRaja-DannyPflughoeft Naturally it depends on the C++ code, but if you compare, say, Intel's implementation of TBB in C++ vs. OMP, TBB was a lot buggier and had bugs lasting for years (one which was caused by awkwardness with destruction order of thread arenas which the developers begrudgingly had to suggest to customers to put sleeps in their code prior to shutdown to make sure the arenas had enough time to destroy themselves). There's issues like that sometimes in C++ code because you are allowed to get so, so much fancier with resource/state management in C++... | |
| Apr 21, 2016 at 14:54 | comment | added | yyny | @BlueRaja-DannyPflughoeft #define malloc(x) my_malloc(x) #define free(x) my_free(x) and you are now debugging memory. With C++ you never know what will be allocated when, because there are so many ways to allocate memory (new, malloc, class constructors, etc.) | |
| Jun 5, 2012 at 22:23 | comment | added | Parris | I've heard people end up essentially rewriting C++ when they develop a pure game engine in C (or develop anything heavy duty in C for that matter). It might be worth it to you. C is cleaner, C++ is kinda disgusting syntax/organization wise IMO. There's also nothing stopping you from alias'ing/redefining things in a nicer way in C++. | |
| Jan 14, 2011 at 16:13 | comment | added | munificent | C++ is a big language, but it's fearsome reputation is spread mostly by people who've just read horror stories and haven't taken the time to learn it. There is a lot to learn, but you get a lot of value in return for that. C++ lets you express lots of things that C simply can't. | |
| Jan 14, 2011 at 13:30 | comment | added | Jari Komppa | C can be understood by mere mortals. C++ seems to have lots of features and edge cases seasoned programmers learn about even after a decade of using it every day for living. | |
| Oct 1, 2010 at 18:55 | comment | added | BlueRaja - Danny Pflughoeft | @Josh: Easier to debug!? C-programs are notoriously difficult to debug, largely due to pointers and memory management. C++ programs (when using true C++ programming idioms, which tend to avoid pointers and memory-management whenever possible) are several orders of magnitude easier to debug. | |
| Aug 24, 2010 at 7:58 | comment | added | Adam Naylor | @Casey & SAHChandler you're both right - IdTech 4 began as IdTech3 (Q3A) but it is written in c++ (or at least the SDK is) | |
| Aug 9, 2010 at 1:08 | comment | added | jsimmons | As well as compilation time, C being simpler means it's often easier to debug. Combine this with a tool like... clang.llvm.org/diagnostics.html and you have quite a powerful setup. | |
| Jul 17, 2010 at 20:09 | comment | added | bruxisma | @Casey id Tech 3 was Quake 3, with id Tech 4 being used in Doom 3 and Quake 4. Id Tech 5 will be Rage, Doom 4, etc. | |
| Jul 16, 2010 at 22:28 | vote | accept | bruxisma | ||
| Jul 16, 2010 at 20:27 | comment | added | Casey | @optician I believe Id Tech4 began life as Quake III? I would have to dig that code out again to confirm. | |
| Jul 15, 2010 at 16:40 | comment | added | optician | Until Id Tech 4 | |
| Jul 15, 2010 at 8:32 | comment | added | Dave O. | id software writes their engines in pure C. | |
| Jul 15, 2010 at 7:01 | comment | added | weiji | Coincidentally, I'm reading Stroustrup's "The Design and Evolution of C++" right now, and he really emphasizes one of his design philosophies for C++ to be "as close to C, but no closer", in particular the performance difference must be negligible. | |
| Jul 15, 2010 at 6:41 | history | answered | munificent | CC BY-SA 2.5 |