GG development team coding philosophy?
by Ivan Lazarte · in Torque Game Engine · 05/06/2005 (12:24 am) · 44 replies
I've started looking through the TGE source in depth and I'm pretty blown away. Despite only coding for maybe 2 or so years, I've seen lots of different projects through many languages through my consulting and job list, DHTML and all related, Actionscript, Perl, TCL, Java, and now C++, I have to say this is the cleaning looking source of anything I've come across. Very nice job.
I was wondering if the garagegames team has any advice or philosophies towards coding that they would be willing to share. I definitely see the "if your subprocess is greater than 20 lines, you're doing something wrong" rule for example.
I was wondering if the garagegames team has any advice or philosophies towards coding that they would be willing to share. I definitely see the "if your subprocess is greater than 20 lines, you're doing something wrong" rule for example.
About the author
#22
05/13/2005 (5:03 pm)
Oh, yeah. Another idiom I use is to put constants in equality comparisons on the left, such as "1 == foo". That way if one of the "=" gets lost the compiler will throw an error. This is good when you hand some code to a Pascal programmer who's just learning C/C++.
#23
Hmmm, although I'm truely flattered that someone said I must be one fart smucker, I say that's a load of crap. I can debug code without having a clue of how it works. A LOT of mistakes are very obvious, and I dont just mean missing semi's and spelling errors. I wrote about it in one of my plans, where I speant days debugging a 30 second problem. Problems are only as hard as you make them. Worse comes to worse, I know exactly how it works by the time I fix it, lol.
05/13/2005 (8:47 pm)
Quote:Some nigh-famous programmer once said "You have to be twice as smart to debug code as you do to write it, so any time you write your cleverest code, BY DEFINITION, you are incapable of debugging it"
Hmmm, although I'm truely flattered that someone said I must be one fart smucker, I say that's a load of crap. I can debug code without having a clue of how it works. A LOT of mistakes are very obvious, and I dont just mean missing semi's and spelling errors. I wrote about it in one of my plans, where I speant days debugging a 30 second problem. Problems are only as hard as you make them. Worse comes to worse, I know exactly how it works by the time I fix it, lol.
#24
There are plenty of concrete reasons for tabs as well. But the two I'll use are...
1. All Tabs can be EASILY converted to any # of spaces you choose in almost any editor that is worth a crud, but you cannot covert all spaces into tabs.
2. I have a program that I can drop into a directory and it will remove ALL the tabs and returns from all of the .cs files. The result is one nicely compacted line of code in each file. I said "remove's 'ALL' tabs and returns". Try that with spaces and get back to me with your results.
05/13/2005 (9:14 pm)
BTW, about this...Quote:there are concrete reasons to go with spaces that can't be countered by the tab zealots (who are wrong).
There are plenty of concrete reasons for tabs as well. But the two I'll use are...
1. All Tabs can be EASILY converted to any # of spaces you choose in almost any editor that is worth a crud, but you cannot covert all spaces into tabs.
2. I have a program that I can drop into a directory and it will remove ALL the tabs and returns from all of the .cs files. The result is one nicely compacted line of code in each file. I said "remove's 'ALL' tabs and returns". Try that with spaces and get back to me with your results.
#25
But it's true, a lot of problems are rather silly and can be fixed without deep understanding.
Write code that is exactly as clever as it needs to be, no more, and you'll be set.
05/13/2005 (11:00 pm)
Dang... all this terrain implementation and subsequent debugging work would have gotten done LOTS of faster. I keep getting slowed down by having to understand what I'm doing before I can make it work... :-/But it's true, a lot of problems are rather silly and can be fixed without deep understanding.
Write code that is exactly as clever as it needs to be, no more, and you'll be set.
#26
And as far as converting them to tabs, I don't see why it would be any harder to go the other way around. Rather than searching for a /t to turn into " ", search for " " and convert it to /t. Writing such a tool should be trivial. grep could probably handle it just fine.
Once you have the opportunity to use your Editor-du-jur's "tabs->spaces" command, it's already too late. Those tabs have been interpreted as "N spaces" (and the N is almost certainly wrong), and any work the previous programmer put into lining everything up all nice and purdy has already been destroyed.
My 'N' used to be 4, then 3, and is now 2. I'd be perfectly happy with any of those settings, or 8 for that matter (though more than a couple levels of nesting becomes untendable at that point). Gonzo's is probably !2, and God knows what Ben's PREFERENCE is. We could figure out what he uses easily enough by looking at Torque's indentation.
Trumping the whole "cross-editor consistency" things is going to take some doing for you tab-keepers, but if you can come up with a compelling reason for keeping tabs, I'm all ears.
I suspect that many of you who preffer tabs haven't worked with other programmers who used other editors. Once you have, the pain you feel and inflict becomes immediately obvious. Anyone who wants the lives of those around them to Not Suck switches to spaces, if they ever used tabs to begin with.
----
Fixing bugs and understanding code:
Yes, there are bugs that can be fixed without having any understanding of what is meant to be accomplished in a given section of code.
That's pretty blatant. Uninitialized variables, unreleased resources, refering to released resources, most "off by one" errors, things of this nature. All can be spotted without knowing precisely what is going on. These are all what I'd call "Programming domain" bugs (if I had to whip up a classification on the spot, like now).
"Problem domain" bugs, on the other hand, require that you know what is supposed to be happening so you change the code in question. Just poking at it till it behaves is MUCH more likely to break something else even when you finally get the expected behavior out of the code in question. There's also the "even number of sign errors" phenomenon. Two bugs that happen to cancel one another out.
For example: I work in PDF, using a library that matches Adobe's published API. I need to know PDF in general and this API in specific before I can diagnose many of the problems I am confronted with on a daily basis. I need to know what the code is and is not doing before I can fix it. If a "Widget" type annotation's dictionary is missing it's "AA" key, I need to know that it's a form field that is missing it's "actions", so I can go looking for something like "SetFieldActions()" and use it on the offending field. No amount of C++ knowledge is going to help you here.
In the distant past, I had some Very Clever code written to handle the "transformation matrix" of text... text that could be rotated, and had to appear on a rotated page. My first draft of this code was Clever. It worked (barely), and I knew where half of a pair of "sign errors" lived, but was utterly baffled by the other half. I later rewrote the code to compute the different parts of the matrix individually (rotate, scale, translate) rather than doing them all at once (big freakin mess, believe me). This far-less-clever code was easy to debug. No sign errors (that I ever found anyway;).
05/16/2005 (10:44 am)
@Gonzo: Forgive me, but your two reasons aren't exactly swaying my opinion. Yes, you've got two easy ways to go from tabs to spaces, but you have yet to present me with a reason to stick with tabs in the first place. "They can become spaces" isn't good enough I'm afraid.And as far as converting them to tabs, I don't see why it would be any harder to go the other way around. Rather than searching for a /t to turn into " ", search for " " and convert it to /t. Writing such a tool should be trivial. grep could probably handle it just fine.
Once you have the opportunity to use your Editor-du-jur's "tabs->spaces" command, it's already too late. Those tabs have been interpreted as "N spaces" (and the N is almost certainly wrong), and any work the previous programmer put into lining everything up all nice and purdy has already been destroyed.
My 'N' used to be 4, then 3, and is now 2. I'd be perfectly happy with any of those settings, or 8 for that matter (though more than a couple levels of nesting becomes untendable at that point). Gonzo's is probably !2, and God knows what Ben's PREFERENCE is. We could figure out what he uses easily enough by looking at Torque's indentation.
Trumping the whole "cross-editor consistency" things is going to take some doing for you tab-keepers, but if you can come up with a compelling reason for keeping tabs, I'm all ears.
I suspect that many of you who preffer tabs haven't worked with other programmers who used other editors. Once you have, the pain you feel and inflict becomes immediately obvious. Anyone who wants the lives of those around them to Not Suck switches to spaces, if they ever used tabs to begin with.
----
Fixing bugs and understanding code:
Yes, there are bugs that can be fixed without having any understanding of what is meant to be accomplished in a given section of code.
if (foo) bar(); baz();
That's pretty blatant. Uninitialized variables, unreleased resources, refering to released resources, most "off by one" errors, things of this nature. All can be spotted without knowing precisely what is going on. These are all what I'd call "Programming domain" bugs (if I had to whip up a classification on the spot, like now).
"Problem domain" bugs, on the other hand, require that you know what is supposed to be happening so you change the code in question. Just poking at it till it behaves is MUCH more likely to break something else even when you finally get the expected behavior out of the code in question. There's also the "even number of sign errors" phenomenon. Two bugs that happen to cancel one another out.
For example: I work in PDF, using a library that matches Adobe's published API. I need to know PDF in general and this API in specific before I can diagnose many of the problems I am confronted with on a daily basis. I need to know what the code is and is not doing before I can fix it. If a "Widget" type annotation's dictionary is missing it's "AA" key, I need to know that it's a form field that is missing it's "actions", so I can go looking for something like "SetFieldActions()" and use it on the offending field. No amount of C++ knowledge is going to help you here.
In the distant past, I had some Very Clever code written to handle the "transformation matrix" of text... text that could be rotated, and had to appear on a rotated page. My first draft of this code was Clever. It worked (barely), and I knew where half of a pair of "sign errors" lived, but was utterly baffled by the other half. I later rewrote the code to compute the different parts of the matrix individually (rotate, scale, translate) rather than doing them all at once (big freakin mess, believe me). This far-less-clever code was easy to debug. No sign errors (that I ever found anyway;).
#27
arguably you could search for multiple spaces , but then again the chance that you have three spaces in some other part of your code (maybe comments?) then your code would break.
To me a simple tab hit is much easier than spaces, but then again thats what I'm used to. I'm also used to the space that the tab gives. Plus as Gonzo said its easy to make a program to search for /t but then again making it search for spaces is nearly impossible unless you never use multiple spaces other places in your code.
The arguments to support spaces are good ones, mentioned by GG and some others... though I would disagree with the ability to convert spaces to tabs.
I think a lot of it is driven by the necessity of the circumstance. For working with a large team of coders then it would seem to be a good idea to use spaces. Trying to train myself to do so now. Gonzo's method is definately viable in converting tabs to spaces. If your a lone coder then it probably doesn't matter, that extra time to space it if your used to tabs probably isn't worth it. Then again thats just my take on it ;)
EDIT: though I'll admit its fairly easy to switch out tabs to spaces
05/16/2005 (10:49 am)
Actually searching for a " " and turning it into a /t would pretty much kill your code, unless you never use any spaces other than in starting a line...arguably you could search for multiple spaces , but then again the chance that you have three spaces in some other part of your code (maybe comments?) then your code would break.
To me a simple tab hit is much easier than spaces, but then again thats what I'm used to. I'm also used to the space that the tab gives. Plus as Gonzo said its easy to make a program to search for /t but then again making it search for spaces is nearly impossible unless you never use multiple spaces other places in your code.
The arguments to support spaces are good ones, mentioned by GG and some others... though I would disagree with the ability to convert spaces to tabs.
I think a lot of it is driven by the necessity of the circumstance. For working with a large team of coders then it would seem to be a good idea to use spaces. Trying to train myself to do so now. Gonzo's method is definately viable in converting tabs to spaces. If your a lone coder then it probably doesn't matter, that extra time to space it if your used to tabs probably isn't worth it. Then again thats just my take on it ;)
EDIT: though I'll admit its fairly easy to switch out tabs to spaces
#28
1) Replacing ANYTHING in comments isn't going to break code.
2) Replacing spaces IN STRINGS with /t isn't going to break code (though it could screw up your formatting, but that's just another argument for keeping spaces now isn't it?) =)
3) Replacing spaces in conditions/loops/you name it isn't going to break code.
Changing one form of whitespace into another isn't going to break code. I challenge you to put forth any code that will be broken by a search and replace command that replaces any (fixed) number of spaces with a single tab.
PS: Ouch. Putting "spacespacespace" outside a 'code' block is translated into "space". Perhaps that's where your confusion lies. I'd originally placed 3 spaces in the quotes as an example.
PPS: "Pretty much kill your code" != "break code". My point was that replacing some number of consecutive spaces with a single tab character is exactly the same (in terms of 'doability') as replacing tabs with some number of spaces. Whether or not it is ADVISABLE is another matter entirely.
05/16/2005 (10:57 am)
@King Tut BoB1) Replacing ANYTHING in comments isn't going to break code.
2) Replacing spaces IN STRINGS with /t isn't going to break code (though it could screw up your formatting, but that's just another argument for keeping spaces now isn't it?) =)
3) Replacing spaces in conditions/loops/you name it isn't going to break code.
Changing one form of whitespace into another isn't going to break code. I challenge you to put forth any code that will be broken by a search and replace command that replaces any (fixed) number of spaces with a single tab.
PS: Ouch. Putting "spacespacespace" outside a 'code' block is translated into "space". Perhaps that's where your confusion lies. I'd originally placed 3 spaces in the quotes as an example.
PPS: "Pretty much kill your code" != "break code". My point was that replacing some number of consecutive spaces with a single tab character is exactly the same (in terms of 'doability') as replacing tabs with some number of spaces. Whether or not it is ADVISABLE is another matter entirely.
#29
Your right when putting it myself "spacespacespace" it truncated it, my argument that it would kill your code was vs " "
would become
but then again that was just a board quirk so I don't think that would be challenged
... "spacespacespace" could just contradict the original purpose of cleaning your code.
EDIT: All in all I would support using spaces as to ensure compatability... then again if someone were to consistently convert tabs to spaces then I don't see how that would be any different. I'll admit I haven't been in enough situations to run into problems of tabs being converted to spaces, I guess it could be conceivable though.
05/16/2005 (11:03 am)
True it wouldn't break your code, but as far as the whole idea behind it of keeping it nice and neat, putting tabs in unexpected places would kill its visibility as well as string formatting.Your right when putting it myself "spacespacespace" it truncated it, my argument that it would kill your code was vs " "
int myNum; myNum = 5;
would become
int/tmyNum myNum/t=/t5;
but then again that was just a board quirk so I don't think that would be challenged
... "spacespacespace" could just contradict the original purpose of cleaning your code.
EDIT: All in all I would support using spaces as to ensure compatability... then again if someone were to consistently convert tabs to spaces then I don't see how that would be any different. I'll admit I haven't been in enough situations to run into problems of tabs being converted to spaces, I guess it could be conceivable though.
#30
Sorry didn't realize you were only talking spacespacespace
05/16/2005 (11:06 am)
Well, in the case of torquescript, where you use spaces to seperate the values of a point or vector, replacing those with tabs would break the script, would it not ?Sorry didn't realize you were only talking spacespacespace
#31
Given the same number of spaces as your normal tab (whatever number that might be), it shouldn't be difficult to convert any instance of that number of spaces into a single tab character. Doing so would be transparent to you: the on-screen appearance of the file wouldn't change.
This would not "kill your code", because it's appearance would be maintained.
But I've still to hear a reason for having tabs in the first place. ;)
If you're using tabs, and you're planning on Playing Well With Others, you need to retrain yourself. Learn ctrl+arrow. Learn to select multiple lines and tab/shift+tab to adjust their indention. If you're not using an editor that supports these functions, I strongly recommend that you switch.
Notepad is a joke. Wordpad is an INSULT (variable size tabs?! Variable width fonts?! Obscenity!!!). Get a basic programming editor. There are a LOT of free ones floating around out there. vi, emacs, jEdit, and on and on. Yes, you'll have to learn a few things, but you'll find, in the long run, that the time was invested and that the payoff is well worth it.
And once you've used a GOOD editor/IDE, it's hard to go back. After using IntelliJ, using .NET is down right painful. It shows that MS's products only kick ass until there's no more competition, then its off to stagnation-ville. Look at IE. It's CALCIFIED. The Mozilla clan (I preffer firefox) kick's their keister left right and center.
05/16/2005 (11:18 am)
Lets see if I can't clear this up a bit.Given the same number of spaces as your normal tab (whatever number that might be), it shouldn't be difficult to convert any instance of that number of spaces into a single tab character. Doing so would be transparent to you: the on-screen appearance of the file wouldn't change.
This would not "kill your code", because it's appearance would be maintained.
But I've still to hear a reason for having tabs in the first place. ;)
If you're using tabs, and you're planning on Playing Well With Others, you need to retrain yourself. Learn ctrl+arrow. Learn to select multiple lines and tab/shift+tab to adjust their indention. If you're not using an editor that supports these functions, I strongly recommend that you switch.
Notepad is a joke. Wordpad is an INSULT (variable size tabs?! Variable width fonts?! Obscenity!!!). Get a basic programming editor. There are a LOT of free ones floating around out there. vi, emacs, jEdit, and on and on. Yes, you'll have to learn a few things, but you'll find, in the long run, that the time was invested and that the payoff is well worth it.
And once you've used a GOOD editor/IDE, it's hard to go back. After using IntelliJ, using .NET is down right painful. It shows that MS's products only kick ass until there's no more competition, then its off to stagnation-ville. Look at IE. It's CALCIFIED. The Mozilla clan (I preffer firefox) kick's their keister left right and center.
#32
So the fact that it takes less time to navitgate and place a tab isn't a reason ?
I'm not seeing any reasons not to use either, if it is so simple to convert.
05/16/2005 (11:24 am)
"But I've still to hear a reason for having tabs in the first place"So the fact that it takes less time to navitgate and place a tab isn't a reason ?
I'm not seeing any reasons not to use either, if it is so simple to convert.
#33
I'm a pretty agreeable person, in fact right now I agree and support both sides, but don't get too carried away :)
Here are some links supporting Notepad (these were originally posted by Gonzo in another thread, I'm respectfully repeating them).
Pat Wilson ~ Employee
Chris Gatterbauer says "Real Men Use Notepad"
Jeff Tunnel (recommending NotePad)
Jeff Tunnel (recommending NotePad Again)
"Edit: No need for Tribal IDE either. Just use Notepad."
Devon Ly ~ Associate
05/16/2005 (11:25 am)
Quote:Notepad is a joke. Wordpad is an INSULT (variable size tabs?! Variable width fonts?! Obscenity!!!). Get a basic programming editor.
I'm a pretty agreeable person, in fact right now I agree and support both sides, but don't get too carried away :)
Here are some links supporting Notepad (these were originally posted by Gonzo in another thread, I'm respectfully repeating them).
Pat Wilson ~ Employee
Chris Gatterbauer says "Real Men Use Notepad"
Jeff Tunnel (recommending NotePad)
Jeff Tunnel (recommending NotePad Again)
"Edit: No need for Tribal IDE either. Just use Notepad."
Devon Ly ~ Associate
#34
Though I agree that IE is behind the times, especially with keeping up on standards. They still hold the majority of users, at least the mainstream. This may be changing, but it hasn't yet, and you never know what MS will pull out of their hats.
Its like the argument against Windows... yes it may suck on many levels, but if you refuse to make games that play on it your limiting yourself (same goes for those against Macs).
the point that MS IE has gotten out to so many people proves that
Isn't exactly true in every case. Obviously they have not yet in marketing ? Influence? Microsoft puts out some nice products, not all of them, but the .net compilers are quite nice in my opinion. A lot of MS technology is used to support very commercial quality product and frameworks, like .asp.
This is all coming from a PC Tech Linux-php-MySQL fanboy. (btw I'm the guy that usually says MS sucks ;) best to keep open minded about these type of things, your only hurting yourself if you don't.
05/16/2005 (11:31 am)
Quote:Look at IE. It's CALCIFIED. The Mozilla clan (I preffer firefox) kick's their keister left right and center.
Though I agree that IE is behind the times, especially with keeping up on standards. They still hold the majority of users, at least the mainstream. This may be changing, but it hasn't yet, and you never know what MS will pull out of their hats.
Its like the argument against Windows... yes it may suck on many levels, but if you refuse to make games that play on it your limiting yourself (same goes for those against Macs).
the point that MS IE has gotten out to so many people proves that
Quote:The Mozilla clan (I preffer firefox) kick's their keister left right and center.
Isn't exactly true in every case. Obviously they have not yet in marketing ? Influence? Microsoft puts out some nice products, not all of them, but the .net compilers are quite nice in my opinion. A lot of MS technology is used to support very commercial quality product and frameworks, like .asp.
This is all coming from a PC Tech Linux-php-MySQL fanboy. (btw I'm the guy that usually says MS sucks ;) best to keep open minded about these type of things, your only hurting yourself if you don't.
#35
05/16/2005 (11:37 am)
Also I find that using notepad for scripting is great training. I find that I learn to keep my code structured (since I don't have color prefixing and syntax highlighting) and I learn to debug and check my code quite proficiently. Eight out of Nine of my T2D tutorials reside 100% in scripting, I used notepad to create all of them. In fact I used notepad to create the tutorial text, one of them being 88 pages long, and used notepad to create the php scripts to convert from board to html format and back. As well as using notepad to create php to access a mySql database to store the unofficial faq for updating and output board/html format... not bad for a "joke" and an "insult"? 
#36
05/16/2005 (11:38 am)
I've advanced to using jEdit now :P
#37
EDIT: with that I'll opt out. Interesting thread, good to hear from GG and their tips and suggestions. I'm personally converting to using spaces, though I'm still using either notepad for scripting or my ingame (very simple) editor =p
05/16/2005 (11:40 am)
Lol =p though considering you formerly used notepad it probably can stand to reason that it isn't the bane of programmers existence EDIT: with that I'll opt out. Interesting thread, good to hear from GG and their tips and suggestions. I'm personally converting to using spaces, though I'm still using either notepad for scripting or my ingame (very simple) editor =p
#38
Tabs vs spaces: Remember that there are several completely different issues here to address:
Input vs output: The tab fans claim that they don't want to type more. Fine. A good IDE converts the tab key to the proper indentation/alignment. Yet another reason to drop Notepad and get a real editor. Eliminate more drudgery. But don't put a bandaid on the symptom, the extra work imposed by your editor to get indentation right. Less typing is not a good argument for tabs, it's a good argument for switching editors.
The real value of spaces is in output, not input, and in non-editing tools, particularly revision control and presentation (visualization) tools. It insures that everyone sees a consistent look and alignment, even when using tools where there is a fixed tab representation (like a web browser using the PRE tag).
Converting: Simple blind replacement of a string of spaces with tabs is probably not a good idea. If you only want to convert stuff at the beginning of a line, then include "beginning of a line" in your string replacement expression. My editor lets me replace "^[ \t]+" and other regular expressions. It also can do smart indenting and the indentation is handled by a scripting language so it's extensible and highly configurable. (I just requested a new indentation mode that lets one use tabs for indentation and spaces for alignment of continued lines, and the author will be adding that in the next major version. I encounter a lot of different tab/space conventions in others' code.)
05/16/2005 (11:56 am)
Notepad vs IDE: Are you Notepad fans also planning to convert all your script and C++ to assembly language? The point of a programmer's editor is that it takes the drudgery out of coding. You still have to understand the algorithms, but you no longer have to worry about stupid typos if the IDE is smart enough and throws a red flag on them as soon as you type them.Tabs vs spaces: Remember that there are several completely different issues here to address:
Input vs output: The tab fans claim that they don't want to type more. Fine. A good IDE converts the tab key to the proper indentation/alignment. Yet another reason to drop Notepad and get a real editor. Eliminate more drudgery. But don't put a bandaid on the symptom, the extra work imposed by your editor to get indentation right. Less typing is not a good argument for tabs, it's a good argument for switching editors.
The real value of spaces is in output, not input, and in non-editing tools, particularly revision control and presentation (visualization) tools. It insures that everyone sees a consistent look and alignment, even when using tools where there is a fixed tab representation (like a web browser using the PRE tag).
Converting: Simple blind replacement of a string of spaces with tabs is probably not a good idea. If you only want to convert stuff at the beginning of a line, then include "beginning of a line" in your string replacement expression. My editor lets me replace "^[ \t]+" and other regular expressions. It also can do smart indenting and the indentation is handled by a scripting language so it's extensible and highly configurable. (I just requested a new indentation mode that lets one use tabs for indentation and spaces for alignment of continued lines, and the author will be adding that in the next major version. I encounter a lot of different tab/space conventions in others' code.)
#39
05/16/2005 (12:57 pm)
Okay, so I got a little carried away there. Took my meds, all better now.
#40
- Brett
PS: Anyone want to correct this since my brain may not be working right?
05/16/2005 (1:34 pm)
Gonzo, I lost track of this thread but found it again only to rise to the challenge of replacing spaces with tabs. In most cases you want to replace spaces with tabs only if the tab equals your space count, so I present:%sed -e s/[^"|']{1}\S*\s{3}\S*[^"|']{1}/\t/gNot being the best at writing regular expressions, but I think this will replace any 3 consecutive spaces, not enclosed in quotes and surrounded by any non-whitespace, with a tab. Now, I could be totally off my rocker, but usually where a simple search/replace fails, a regular expression will rule.- Brett
PS: Anyone want to correct this since my brain may not be working right?
Torque Owner Kenneth Porter
When I see a raw array in code that's not performance critical, I cringe. One should be using a STL container to avoid those end-of-array overwrites we all come to know and despise.
Plaugher used to have a series in CUJ that covered one C++ header file each month, and that was a great way to learn the STL from under the hood, seeing the difficulties in implementing it.