I found this part of his article to be interesting. I'm working through a CS degree and learning C++ for the first time after cutting my teeth on Python and C#. What exactly does he mean by "(restrained) C++"? He mentions a contract studio using the STL and boost. We are using the STL in our data structures class...does John Carmack eschew the STL and roll his own data structures?
Kids these days with their allocations and virtual memory. shakes fist
You don't need std::vector if you don't need dynamic memory allocations. Game programming and systems programming is a whole lot different than web or desktop development.
You can statically allocate at the start of a game, level, and frame.
From the original article: OpenAL appears to have a limit of 1024 sound buffers, which we bumped into. We could dynamically create and destroy the static buffer mappings without too much trouble, but that is a reasonable number for us to stay under.
It also sounds like Carmack is loading an entire level as a memory mapped file and then doing reads into specific indexes within the file.
Take a look at the source code that id has open sourced. That's the best way to get a feel how this style of development works. I believe RtCW is their last release.
ftp://ftp.idsoftware.com/idstuff/source/
http://github.com/monoid/rtcw-rebirth
Actually, I'm 38...bit of a late starter :) Thanks for the reply and link. Modeling and simulation is my area of interest (I work in civil and environmental engineering), so it will be interesting to see what patterns will work best.
I consider myself a decent programmer but I have more trouble reading template heavy C++ than I do haskell code. To me, restrained C++ means keeping the unreadable bits outside the code base and isolated in their own library, like Boost :)
One problem with C++ templates is that they're infectious. You're right that the Boost source code is quite unreadable compared to vanilla C++, but even using Boost types and algorithms in your own code often makes it impenetrable, too.
Template meta programming is very neat stuff, but the problem is that it's basically another language that lives on top of your language. Except that it's not a full-fledged language so it lacks all of the features that keep other programming languages manageable. It's like assembly code, except instead of just twiddling some bits in registers and RAM you're working with a far more complicated entity (an entire program), making the problem that much worse.
C++ lends itself to a large variety of different programming styles and paradigms. C++ also lends itself to premature baldness, by developers ripping their hair out trying to make systems developed in different styles interact with each other.
A popular thought is that any given team or company should pick a particular subset of those styles -- and perhaps a subset of C++'s features -- and use them to the exclusion of others.
Nice, I read this a long time ago before learning C++. It's interesting (and reassuring) that some of the stuff we are learning is considered bad practice by Google.
