id Tech 4 and C++

[dreadlorde]

[Teiman]

[FrikaC]

IIRC, Carmack said at one point the reason for switching to C++ was that whenever a licensee bought an idTech license (at the time, Quake 3 engine license) the first thing they'd do is convert the code from C to C++, so for the sake of licensees they'd make all their engines in C++ now.

Over any perceived language benefits, I suspect the real reason all the licensees switched to C++ is that because the language is de facto for college CS courses. It's incredibly difficult to find C programmers or reinterpret_cast college educated C++ programmers into writing good C. In turn, the reason all the CS courses are C++ is because of enterprise level software engineering.

[mh]

My understanding at the time was that it's just the game code that's C++, and that at least the renderer is still C. Unfortunately I don't have any reference to back that up at the moment though.

Regarding theoretical advantages of C++ over C, I think it's still a little shady. Free variable declaration anywhere you want is genuinely liberating (although a fully conformant C99 would give you that too), and if you're doing any COM programming or using 3rd party libs that primarily have a C++ interface it makes life easier. The improved type safety also helps catch a lot of errors before they happen.

OO constructs can more logically model certain things and it can make sense to used them in those contexts, but I've also seen plenty of cases where OO was used but it shouldn't have been (D3DXVECTOR as an argument to ID3DXMatrixStack::RotateAxisLocal was one specific annoying example) and which only serves to make things more awkward.

[dreadlorde]

[frag.machine]

[mh]

Not necessarily always better. If an algorithm or other piece of logic is best and most clearly expressed procedurally then I say "code it procedurally" - going OO with it can only lead to obfuscation (the reverse is also true).

Writing the code first time round is only half the battle remember; you have to maintain it going forward, and the person who takes over your job when you've left (or who fills in for you when you're on leave) will also have to maintain it.

Regarding compile times, DirectQ is C++ (purely to make DirectX calls easier) and I would guess it takes on average 5 to 10 times longer to compile than Win/GL/DarkPlaces/etc (or at least it certainly feels like it does). When you're measuring compile times in seconds that's peanuts; for really large projects you've probably just lost a few hours productivity (you may not have the luxury of nightly builds if you need to get a critical bugfix done now).

For the record, DirectQ does use classes in certain parts of it's code: the menus are all OO (there's even some multiple inheritance in there), cvars and commands are OO, the progs interpreter is OO, lightmaps are OO (although in hindsight they didn't really need to be), memory is OO. The renderer and base client and server code are purely procedural however and I don't see a convincing argument for going OO with them.

[frag.machine]

[FrikaC]

[dreadlorde]

[frag.machine]

[Baker]

[Spike]

[mh]

[Teiman]

OOP is different toolset, that let you solve problems in a different way, not totally compatible with the procedural way.
So wen you choose OOP theres a trade-off.

Choosing C, lets you use *all* of what the "procedural way" has to offer. Choosing C++ lets you use part of that, and activate a whole new continent of skills and tools.

I am a different programmer wen I write C than C++. Oh, and I am a much [s]better[/s]powerfull programmer wen I write in a OOP powered language.