So, here’s a quick followup, in order to fully exploit my 15 minutes of fame!

First, I highly recommend any newcomers read Doug Turnure’s comment on my previous post. It is an interesting read, and seems surprisingly frank about the problems with Connect as it is today. And where I would normally have expected some canned PR speech about how all the perceived problems aren’t actually problems, or can’t reasonably be fixed, it actually states that the problems are real, and that they will be fixed. Thanks, Doug!

Of course, words are cheap, and it remains to be seen whether any of this will actually result in tangible improvements to Connect. But knowing that someone within Microsoft is actually working on it is a lot better than nothing.

But being the cynical and demanding bastard that I am, I worry that this is only brushing the surface. Because the problem is not just that bugs get forgotten on Connect. Let’s try to separate the issues a bit:

Bugs are forgotten

As we saw, bugs are left to languish until they are mentioned on Twitter, implying that the way to get a bug fixed is not to bother with Connect, but instead to make a lot of noise about it on social media. Doug answered this quite clearly, saying that bugs currently “fall through the cracks”, which can, should and will be prevented in the future. That’s great, but it doesn’t solve the second part of the problem:

Even when bugs don’t fall off the radar, the way they’re handled is still broken

Bugs seem to be treated completely randomly once they’re entered into Connect. Even if they don’t “fall through the cracks”, they are still treated to a line of over-zealous moderators or whatever they are, who seem to be competing on who can close the most issues the fastest. Bugs are closed haphazardly, sometimes as a duplicate of a bug reported on an internal system that customers can’t see, sometimes as “won’t fix”, and sometimes as “won’t fix”, but with a comment saying that it may get fixed for a future release (which means it’s not quite “won’t fix” after all).

Sometimes the same scenario will result in a “deferred” status (which makes a lot more sense than “won’t fix”), and sometimes the bug will be closed as “by design”. Sometimes they’re Resolved as won’t fix, and other times they’re closed as won’t fix. What’s the difference? Are statuses assigned completely at random, or does it just look that way?

Why are issues closed when the team doesn’t have time to fix them in the upcoming release? They’re still bugs, and until a decision is made to never fix the bug, it is hard to see why they should not be considered as open, or unresolved, at least from the users’ point of view (what status it is given internally is of course up to Microsoft. But when customers see a bug closed as “won’t fix” merely because “we don’t have time to fix this in time for the next release”, they’re going to see red, and for good reason.)

Is any or all of this a consequence of the messy internal systems that Doug described, or is it that new bugs are processed and cataloged badly (whether due to the responsible staff receiving insufficient training, the policies they’re supposed to follow being unclear, or the tools they use being, well, broken)? I don’t know, but something is clearly wrong. And it is not just that bugs fall through the cracks and are forgotten.

So the real problems go deeper…

What needs to be done

Once the “superficial” problems with Connect are fixed, the next step is to make sure bugs reports are actually handled correctly: that bugs aren’t closed with “won’t fix”, unless that is actually what the responsible team intends; that duplicate bug reports are closed either with the same reason, or marked as duplicates, and that in general, reporting a bug gives the user the impression that “the bug report isn’t participating in some random lottery, where a random person will eventually close it with a random reason”.

But even then, we’re not quite home free. Because even when a bug is “fixed”, there’s a significant problem:

It hardly ever is!

When a bug is marked as “fixed“on Connect, it usually means “we have fixed this bug internally, in our trunk, and at some unspecified point in the future, we will release some unspecified product built from this source tree”.

In other words, the bug has not been fixed in the product where it was reported. The bug may have been reported in Visual Studio 2010, but it was “fixed” in Visual Studio 2012 (or whatever).

That’s not what “fixed” means, is it? A bug is fixed when it is no longer present in the product where it was reported. In other words, if a bug was reported against VS2010, then I’d consider it “fixed” when the following conditions are true:

• the bug has been fixed in the VS2010 source tree, and
• the fix is available to customers who own VS2010, or at the very least, has been scheduled for availability to users of VS2010.

Of course, some bugs are so insignificant that it’s not worth pushing an update out to users of the current product, and sometimes a fix would be so complex that it can’t be reasonably implemented in the product. Of course there are cases where it makes sense to implement the fix in the trunk of your source tree, and not in the product version where it was reported. But at least give it a different status than “fixed” then.

When a bug is “fixed” in Connect today, the message to the person who reported the bug basically boils down to this:

We have identified the problem, and if you buy a different product, priced at several thousand dollars¹, to be released in a year or two, you won’t experience it any more”.

Gee, really? So where does Connect enter into it? I’m pretty sure I can do that today without ever submitting the bug report to Connect. I could just buy a different OS or IDE. I hear a lot of people are pretty happy with XCode, for example.

Of course, exacerbating this problem, Visual Studio upgrades tend to be nontrivial for large code bases. The format of solution and project files is generally incompatible between versions (even when the only actual change to the format is an incremented version number), so not only does the user have to wait for a completely separate product to be released, and then buy it at the usual price, they also have to go through a potentially painful upgrade process… Just to see the fix to a bug they reported two years ago.

Even if all the other problems are fixed, this one still ensures that reporting bugs on Connect will feel like a waste of time. If we’re practically guaranteed that the product we reported the bug against won’t ever be fixed, why bother reporting the bug at all?

So it’s not just Connect

So this plays into another of my pet peeves about Visual Studio: I have no clue whose decision this is, and if it is actually an active decision made by someone who thinks it is a good idea, or if it is simply a fossilized holdover from the mid-80’s that no one have thought to change, but the policy of never ever improving on a released product has got to go. If I report a bug on VS2010 and you claim to have fixed it, I want the fix. If you don’t actually fix VS2010, then you haven’t fixed the bug that I reported. And if you’re not going to fix the bugs I report, where’s my incentive for reporting them?

Of course, once we accept that bugs should actually be fixed, when practically possible, it is worth asking why the same shouldn’t apply to new features and other improvements.

If you have a better compiler than the one I’m using, it really seems to be a win-win situation if you let me use it. I get to use a better compiler, I get more value out of the product I bought, and I am more inclined to buy VS vNext as well, if I know that it too will actually improve over time. Forcing me to use an, on average, 18 months old compiler doesn’t seem like good sales tactics.

Of course, not all VS users are affected equally by this. When I worked with .NET, this bothered me less, because the VS compiler set the pace: the language got updated when the compiler said so, and there were no alternative implementations to speak of. Who cares if your compiler is 2 years old? The language evolves in lockstep with the compiler anyway. Sure, I’d still have loved to see improvements to the IDE itself, but I knew there would be little point in updating the compiler out of band.

But now that I work with C++ every day, it drives me nuts. The VC++ team is (like any other C++ compiler team) perpetually playing catch-up to an international standard, and to a half-dozen competing compilers. When VC10 was released, it was on par with the competition for about 2 months. Sure, it lacked plenty of features that other compilers supported, but it also supported some that weren’t yet implemented in other compilers. Then, a couple of months later, a new GCC version was released which supported the few features that had previously been unique to MSVC. And after that, we’re witnessing a 2–3 year period of utter stagnation, where the VC++ compiler stands completely still, while all around it, the competition is making huge strides towards compliance with the new C++ standard, and making new features available by the dozen.

How is that a good idea? How does this make Visual Studio look good? Why would I pay thousands of dollars for a product that is obsolete 95% of its lifetime?

And the product doesn’t even need to be obsolete at all. The VC++ team is busy implementing countless improvements to the IDE and the compiler. But they’re being “hoarded”, waiting for the next major release, rather than being shipped out to your paying customers. It is as if someone at the top of Microsoft’s DevDiv considers software to be like fine wine; as if new features should be given a few years in a cold cellar to “mature” before being sold to customers.

Does anyone really think that this makes VS a more attractive product?

Connect is current broken, sure, but the problem goes deeper than a few “forgotten” bugs. Once that is fixed, there seems to be a lot of work to do in making Connect appear worthwhile to users (by giving better, more consistent, feedback on received bugs, and probably also through general site improvements, fixing the UX disaster that it is today), and even once those are solved, end-users are unlikely to notice much actual improvement, unless some changes are made to how the Visual Studio team in general deal with bugs, features and product updates.

At the end of the day, until we, the end-users actually get to benefit from the improvements made as a result of of our bug reports, the system will remain broken.

You can make Connect as responsive, user-friendly and all-round wonderful to use as you like — but if we, the end-users, don’t get to see fixes to the bugs we report, the system is still broken.

Of course, my ranting about this is unlikely to change much. I’m hardly in a position to tell Microsoft how to run their business. But on the other hand, there can be no harm in pointing out what I see as problems. So here we go. :)

1. create a new project of type Win32 Console Application, and under Application Settings in the project wizard, select Console Application and Empty Project.
2. create a single .cpp file
3. add the code int main() {} to it
4. hit build.

You’ll now get the warning (listed under “Errors”, for some reason): IntelliSense: PCH warning: header stop cannot be in a macro or #if block. An intellisense PCH file was not generated.

(I zipped up a solution reproducing the problem here. Note that everything is left at the default settings.

What the f…? How can something so simple break IntelliSense?

I am sometimes amazed at the apparent lack of testing that goes into a release of Visual C++. VC2010 beta 1 had a glaringly obvious bug, where the above program would fail with a linker error. Apparently, no one had thought to test a program which used the standard-compliant main instead of wmain with UNICODE enabled. Sure, it was beta, and you’d expect errors, but something simpler than a Hello World should still work, shouldn’t it?

Now we get spurious IntelliSense errors if we have the audacity to create the tiniest, simplest program imaginable, at the default settings.

Of course, it gets better. Because as we all know, Microsoft Connect is beyond useless, and obviously, some optimistic/foolish VC++ users had already reported the problem with this warning message. Google gave me the following three bug reports:

• this one, closed as By Design
• this, closed as Duplicate
• And of course, no discussion of Connect would be complete without something closed as Won’t Fix

It is one thing that errors that practically leap in the user’s face are allowed to exist in a shipping product at all, that literally the shortest, simplest program possible provokes the bug, but that Microsoft closes such bugs with three different close reasons only serves to underline how utterly useless, random and user–hostile Microsoft Connect is, and it is pretty hard to escape the conclusion that there is something fundamentally wrong with how Microsoft’s DevDiv operates.

I am generally reasonably positive towards Microsoft’s C++ compiler. It’s nothing special, certainly, and Microsoft’s policy of never ever improving an existing product means it is perpetually obsolete compared to the competition, but it generally works, and it has made great strides towards standards compliance. But the quality of the IDE, and of Intellisense, is really absurd, at times. VC2010 seems to have shifted the absurdity of IntelliSense from “it just plain doesn’t work”, to “It works reasonably ok, but imposes some baffling requirements on the code, has some kind of love affair with precompiled headers and seemingly doesn’t even bother with code that doesn’t have one, reports false positive ‘errors’, and lists them in the ‘Errors’ window, along with actual compile errors.”

And Connect is nothing short of an insult towards Microsoft’s customers. It is apparently staffed by monkeys, perhaps assisted by a script that randomly closes issues as “Won’t Fix”, and seems to serve the sole purpose of underlining to Microsoft’s customers, all the errors that will not get fixed.

Here’s another great example I saw in my Twitter feed just two days ago:

Bugs like this in WPF that date back to 2007 (I just hit it in .NET 4.0) makes me lose confidence in Microsoft Connect http://t.co/6IbRGQq

August 11, 2011 21:17 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

Seriously 4 years on a bug that a user just has to drag something and everything busts is a pretty LONG time to not fix that… FOUR YEARS

August 11, 2011 21:21 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

What’s worse is someone submitted a fix to the Connect bug using reflector and fixed the Microsoft code and STILL unfixed 4 yrs later

August 11, 2011 21:23 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

@kellabyte Feedback passed over directly to very senior people in charge of WPF, expect some response

August 11, 2011 21:31 via TweetDeckReplyRetweetFavorite

@TheCATerminator

Valery M

May be a stupid question but why does a couple tweets get more traction than 4 years of people commenting on MSFT Connect? #SystemIsBroke

August 11, 2011 21:37 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

#SystemIsBroke indeed. Why even have Connect, when bugs apparently only get resolved once someone with lots of followers on Twitter complain about it?

And of course, this gem of a response from Microsoft on the bug report itself is really remarkable:

I do understand your concern, but we are beyond our ZBB date, therefore only ship-blocker bugs make the bar at this point. Considering that we have shipped this bug before, it is hard to make a case that we need to fix it in this release since it did not block our previous release. Thank you.

Wait what? I guess this pretty much confirms what we all knew: that once a bug has been closed as “Won’t Fix”, the claims that “we will evaluate this for a future release” are just pretense. What actually happens is that the older a bug gets, the lower priority it’s given, according to some twisted “precedence” principle. “We’ve been able to ignore the bug for X years now, so surely, there’d be no harm in ignoring it one more year”.

Now sure, I’m not particularly concerned about WPF, but it shows that the problems with Connect are not limited to Visual C++ issues.

Dear Microsoft, Connect is broken. And everyone except you knows it.

Hurrah!

Apparently, it’ll take a few months for all the paperwork and such to catch up, and then the final standard will be published by ISO (I haven’t been able to find a clear answer to whether or not this might drag the final release all the way out to 2012, but hopefully, C++0x will be forever known as C++11).

Of course, whenever someone dares to admit this, they’re set upon by everyone and heckled and pestered until they give in and install some VCS. And then they spend a few afternoons moaning about how they “could have been coding instead”.

And it occurred to me that there doesn’t seem to be any short, simple, minimalist guide to setting up and using a VCS system. There are plenty of excellent tutorials and guides which explain everything about everything, and are an amazing resource to those willing to actually spend time to learn how to use their tool.

But newcomers to version control are generally someone who’s willing to give it 2–3 minutes, if it’ll shut everyone else up so they can get back to coding. They’re not interested in knowing what their code looked like 7 months ago, or what exact changes were committed on the 28th of June 2010 at 9:37 pm. And they don’t really see why they’d want to branch and merge their code.

Thus…

The 5-minute guide to Bazaar¹

You can use any VCS you like. But the distributed variants (DVCS) are newer, shinier, more powerful and easier to use. So use one of those. The three main ones are Git, Mercurial (Hg) and Bazaar (Bzr), in decreasing order of popularity (and, subjective alert, increasing order of user-friendliness). In any case, I like Bazaar, so that’s what this guide is going to use.

Install Bazaar

Pick yer poison. Bazaar is available for pretty much any OS. Pick the relevant one, download it and install it. (For Windows, you probably want the standalone installer, not the Python ones — unless you have Python installed, in which case you can pick the Python-based one if you like.

Fire up the command line

On Windows, that’s good old cmd.exe. On OS X or Linux, you’ve got terminals and a half-dozen different shells.²

Now, cd to wherever your code is:

c:\somewhere> cd \dev\myproject
c:\dev\myproject>

Initialize a repository. A repository is a small file-based database storing current and past versions of your code.³

c:\dev\myproject> bzr init
Created a standalone tree (format: 2a)

There we go. Bazaar now assumes that the current directory is what it’s supposed to track. It just created a subfolder with the name .bzr, into which it’s going to store all the versioning data associated with your project. If you ever want to just rip everything Bazaar out of your project, just delete that folder.

Now, it’s time to tell Bazaar which files to track:

Putting files under version control

We’ve probably already got some code, spread over one or more files. There’s almost certainly also some temporary files, intermediate files creating during a build, and your final executable, and whatever else, which we do not want to version control. Your VCS system should track the files needed to build your project. No more, no less.

So we need to divide our code up into these two groups. Files that should be version-controlled, and files that should be left out.

A good start is to ask Bazaar what it sees. If your project is a Visual C++ 2010 project, it might look something like this:

c:\dev\myproject> bzr status
unknown:
  Debug/
  myproject.sdf
  myproject.sln
  myproject.vcxproj
  myproject.vcxproj.filters
  myproject.vcxproj.user
  ipch/
  main.cpp

These are the files and directories which Bazaar found, and which, as it says, are unknown. We haven’t yet told Bazaar anything about them.

Well, running through the list, we can see:

• Debug, where the output of a debug build are stored. It contains a half-dozen different file types, from our myproject.exe to a bunch of build logs, and intermediate build files, manifests and other stuff. It’s all generated during build, so we don’t want any of it.
• The Intellisense database, myproject.sdf, and an associated ipch directory storing some other Intellisense cruft which is also generated automatically.
• The Solution file, which we do want Bazaar to keep track of
• The project file, including the project filters it uses, both of which should be version-controlled, and the .user file containing user-specific configuration. If you’re just one developer, you can let Bazaar track this as well, but with more than one developer, each will probably want his own .user file, so I’ll assume you want to keep it out.
• main.cpp — our actual source code. This should definitely be version-controlled.

Well, we could selectively add the files we wanted, but that would leave us with bzr status being all cluttered up showing files we don’t care about. Instead, we should tell Bazaar to ignore the files we don’t want. Then we can add everything else.

c:\dev\myproject> bzr ignore Debug/
c:\dev\myproject> bzr status
added:
  .bzrignore
unknown:
  myproject.sdf
  myproject.sln
  myproject.vcxproj
  myproject.vcxproj.filters
  myproject.vcxproj.user
  ipch/
  main.cpp

ok, so a very short detour first, We told Bazaar to ignore the Debug directory. (The trailing / tells Bazaar that it should only ignore directories with the name Debug. The command bzr ignore Debug would have ignored both files and directories named Debug.

Note that bzr status now shows us something a bit more interesting. Debug/ has vanished from the eyes of Bazaar. The directory still exists, but we told Bazaar to ignore it, so it does. It is no longer “unknown”. On the other hand, we now have a .bzrignore file, and it is not unknown, it’s “added”. This means that it is registered as something that should be added to Bazaars repository, but it hasn’t actually been done yet. As you might have guessed, this is where it stores the information that Debug/ should be ignored. Feel free to look inside the .bzrignore file, or edit it by hand. There’s no magic in it.

Now, let’s move on and ignore the remaining files:

c:\dev\myproject> bzr ignore Debug/
c:\dev\myproject> bzr ignore /*.sdf
c:\dev\myproject> bzr ignore *.user
c:\dev\myproject> bzr ignore ipch/
c:\dev\myproject> bzr status
added:
  .bzrignore
unknown:
  myproject.sln
  myproject.vcxproj
  myproject.vcxproj.filters
  main.cpp

Pretty straightforward, eh? Note that we can use * as wildcards, allowing us to ignore entire groups of files. We can also use a leading / to indicate that this rule only applies if the pattern matches starting from the root. In other words, we want to ignore .sdf files found in the root, but not in subdirectories, whereas with .user files, we just want a blanket ban. Wherever they’re found, Bazaar should ignore them.

Now our status is down to showing just the files we actually want to add. So let’s just add everything.

c:\dev\myproject> bzr add
adding myproject.sln
adding myproject.vcxproj
adding myproject.vcxproj.filters
adding main.cpp

Here, it’s time for another little word of caution:
We just told bazaar to add everything it can see. It will do so recursively. In my little example, that makes no big difference because I only had one subdirectory, and I already told Bazaar to ignore it. If you have subdirectories that are not ignored, then this command will make Bazaar add everything the files inside them as well, even if they weren’t listed on the bzr status output, which doesn’t look inside unknown directories. So it is possible that the add command just added a bunch of other intermediate files, which you didn’t actually want to put under version control. If so, you can use bzr rm <filename> to selectively remove files from version control again. Alternatively, you can just delete the intermediate files, and when Bazaar tries to add them in a minute, it’ll realize they don’t exist, and figure out that you probably didn’t want to add those after all. Or, of course, you could have played it safe and added only the directory itself (bzr add mydir), after which bzr status would have shown the contents of the directory as well, allowing you to easily see what should be ignored and what should be added.

At this point, either read over the output from bzr add above, or run a bzr status and check the added: section. Make sure that the files you want to add are on the list, and that none of your generated/temporary files are. If your ignore patterns hide too many files from Bazaar, go ahead and edit the .bzrignore file.

Committing changes

Assuming the list of added files now matches what we actually want to add, go ahead and tell Bazaar to commit these changes:

c:\dev\myproject> bzr commit

Or, as I prefer,

c:\dev\myproject> bzr commit -m "initial commit: added files"

When you commit, Bazaar expects a small text message describing the changes that were just committed. With -m you can specify this message directly. If you don’t, Bazaar will open a text editor so you can type the message there, save the file and close the editor.

In both cases, you’ll get this output:

Committing to: C:/dev/myproject/
added .bzrignore
added myproject.sln
added myproject.vcxproj
added myproject.vcxproj.filters
added main.cpp
Committed revision 1.

Now, Bazaar has stored a copy of all the files it knows about (files you just added, and files added previously) inside its .bzr subdirectory. If you ever want to go back and check what your code looked like in revision 1, you just have to ask Bazaar (but I won’t tell you how, because this is supposed to be a short minimalist guide).

Just for good measure, check the status again:

c:\dev\myproject> bzr status

Nothing. Bazaar sees nothing interesting. There are some ignored files, but we’re ignoring those. And there are some other files, which Bazaar already knows about, and they’re unchanged compared to the version Bazaar knows. So it has nothing to say, and is polite enough to say nothing.

This is what we like to see, because it means Bazaar is completely up to date on our code.

Now, go ahead and write some code. Change something in one of your files (in my case, that’ll be main.cpp since that’s the only actual code file I have), and run bzr status again:

c:\dev\myproject> bzr status
modified:
  main.cp

Aha! Bazaar has detected that our file has been modified, and these changes have not been recorded by Bazaar. Well, perhaps that’s because the code doesn’t compile, in which case that’s fine. We only want Bazaar to store the changes that are actually worth storing. The ones that mark an improvement to the code, or the ones we might want to be able to recover later on.

But perhaps these changes are actually something we’d like to keep, in which case we commit them:

c:\dev\myproject> bzr commit -m "Fixed a ton of bugs in main.cpp"
Committing to: C:/dev/myproject/
modified main.cpp
Committed revision 2.

And once again, bzr status is empty because everything is exactly as Bazaar expects it to be. Our code looks exactly like what Bazaar was given in our last commit.

And that is basically it. You’re now using version control. When you add new files to your project, just remember to bzr add them. When you’ve made some interesting changes, run bzr commit to tell Bazaar to store a snapshot of your code as it looks now. Regularly run bzr status in between to check that Bazaar’s view of the world correlates with your own. If it shows any unknown files, get them added or ignored. And if it shows other changes, it provides a list of what changes would be committed if you ran bzr commit now. (And also, a list of which changes would be lost if you accidentally overwrote the modified file).

If you want to look up how a command is used, simply type bzr help <command>.

Of course you can do all sorts of interesting things with your repository now⁴, but you wanted the quick version. As long as you add new files, and regularly commit your changes, other programmers will shut up and leave you alone. When you actually need the more interesting features of your version control system, you can always look them up.

But for now, you can go back to coding, and no longer have to hide when people ask “so do you use version control?”.

See? That wasn’t so bad, was it?

It’s still not quite where I want it to be, but I felt that at the very least, it deserved a proper status page. So here it is. A brand new page on my blog. As I’m still rather busy, I can’t promise that much will happen with the library over the summer, but when something significant happens, that page will be the first to know.

I have been working on it on and off for the last couple of months (although the pace slowed down a lot when I started at my new job), and it is actually in pretty good shape. To the best of my knowledge (it is difficult to be sure when it comes to multithreaded code), there are no race conditions or other nasty bugs. It is basically feature complete, although I’m still working on improving the performance of some of them.

And the documentation is, of course, totally missing. I’ve got everything I wrote for my masters thesis, but a major rewrite is in order since the focus is now very different. Another starting point is this, but obviously, there’s quite a bit of work left on the documentation as well.

But it came up in a discussion with a bunch of quite clever programmers who expressed interest in it, and since it’s always been my intention to release it some day, and since I’m actually getting fairly close to being satisfied with its state, well, I might as well put this up here for the world to see:

DikuSTM lives!

After a month or so of editorial changes, proofreading and integration of the last changes into the draft, it will be sent off for all the national bodies of ISO to vote on, and then we will officially have a much-needed refresh of C++. Barring any major surprises, the process should finish later this year, officially turning C++0x into C++11.

Of course, many new features of C++0x are already available in various compilers, but later this year, all of them will become official.

A few reports from committee members are already trickling out, and no doubt, there will be many more to follow:

I don’t have much more to add, other than to say a big thank you to the brilliant people who have spent an awful lot of their time over the last 11–12 years to make this happen. Of course, there have been a lot of casualties along the way (three “core” features were originally envisioned for C++0x: an optional garbage collector, concepts, and language-level support for threading. Of those, only the third survived, although the two others may still make it into future revisions), but overall, C++0x is a huge improvement to the language. Just a few of the features I am excited about:

• lambda expressions
• threading support
• rvalue references/move semantics
• variadic templates
• nullptr
• static assertions
• and of course, all the library additions: hash tables, regular expressions, type traits, tuples and many others.

As any C++ programmer who reads my blog likely knows, I’m quite fond of both templates and the STL — I feel those are largely what transforms C++ from a clumsy and outmoded language that should’ve died 10 years ago, into a modern, expressive, high-performance and yes, even elegant language that I enjoy using.

This isn’t the first time I come across a rant such as this. Templates are a fairly complex language feature, and they are infamous for causing certain problems (in particular, they can make compiler error messages very verbose, and very hard to understand, and they can hurt compilation time if used carelessly). And the STL is an unusual library, and as such it has a certain learning curve. It doesn’t behave the way you’d typically expect.

But this rant isn’t about these real shortcomings of the two language features. Instead, it is about all the things the author himself doesn’t quite understand about them. And because he doesn’t understand them, he doesn’t like them. (I should mention, in fairness, that this article is around 5 years old. Since then, compilers have gotten better, and the author himself might have changed his mind as well. I know plenty of my opinions about programming, programming languages, libraries and frameworks have changed quite a bit since 2005. So while I have no way of knowing how the author actually feels about the topic today, the best I can do is to read it at face value, and comment on it as it is written. )

In the following, I’ll go through the arguments presented in that rant, and offer my take on each one. Hopefully, at the end, I’ll have shown that templates and the STL aren’t “bad” — that in fact, they enable so major improvements in the way we write C++ code.

1. STL is Poorly Supported By Developer Tools

The author shows two screenshots from Visual Studio, where its built-in Intellisense shows the function signatures for the built-in std::string::compare function as well as the string comparison function from their proprietary string class, MlfString::Equals.

As he correctly points out, the std::string version has a much more complex signature. There are two problems here, though, and he doesn’t distinguish between them:

1. the standard library string class offers five different overloads of the function, where their own class has only three. This means that even if every overload is just as simple as the ones in MflString, there’d still be 66% more information to be presented.
2. the standard library string class is an instantiation of a class template, with a lot of “hidden” default parameters. Intellisense shows all of them, so that instead of simply saying std::string, it says std::basic_string<char, std::char_traits<char>, std::allocator<char> >, and when we have a std::string member function which takes a second string as its parameter, all this has to be duplicated.

Of course, there are good reasons for both of these differences, and yes, they add up to the unavoidable fact that more information has to be conveyed if we want to accurately display the type of, say, a string member function.

But this is missing one fairly important point: you shouldn’t need to look at this at all. The std::string class offers a much simpler way to determine string equality.

Where the author uses this code:

tag->path.compare("/config/analyzer/server/real") == 0

which involves looking up the member function compare to check how it behaves, and involves determining what the not-very-obvious int return value means, std::string offers a simpler solution:

tag->path == "/config/analyzer/server/real"

here, we don’t really need to look up any member functions, and we don’t need to remember what they return. The string just does what we expect. Of course, if you look up the signature of operator==, that’s pretty much as complex as the compare function, but

1. we don’t need to look it up,
2. there are fewer overloads of it, and the overloads that exist have more uniform signatures (they all take two strings in some form or shape, and return a bool) , so even if we do look it up, it is much simpler to read.

And yes, I’ll admit that one of the properties of the STL is that it ends up looking very complex when used incorrectly. But when used correctly, we get code that is simpler to read than his own string class.

2. STL API Syntax is Unclear, the Designers Had No Taste

Here, the author first objects to the terminology of “input” and “output” iterators, saying they should’ve been called “read only” and “write only” iterators instead. And yes, that makes a certain amount of sense, but his next complaint doesn’t:

The very words “Input” and “Output” are even reversed from what might make sense in this case!

The words are chosen for the same reason that we have input and output streams. An input stream is one we can read from, and likewise, an input iterator is one we can read from. An output stream is one we can write to, and just like we can write to an output iterator.

That’s hardly surprising, and in fact, it is only consistent with the standard library stream classes, std::istream and std::ostream, or with the nearly universal concepts of standard input and output (often named stdin and stdout), which are shared between pretty much any language. I don’t often hear people say that “The standard output stream should really be called stdin”. It is an output stream because I can use it to output data. Why should iterators not use the same convention?

Then he returns to beating on std::string, this time, for unknown reasons, comparing it to Java’s string class. This in itself seems quite a stretch, because so far, his point has been that “Instead of C++ with the STL, we should prefer C++ without the STL”. So how is a comparison to Java at all relevant? At the same time, he conveniently leaves out the thing that would be relevant: a comparison with the same code expressed without the STL.

So let’s see if we can remedy that:

For reference, the problem we wish to solve is that of determining if a string begins and ends with certain other strings.

here’s his Java code:

String filePath = "/tmp/downloaded.exe";
if ((filePath.startsWith("/tmp")  && (filePath.endsWith(".exe")))
    // fits the pattern.

and here’s his C++ code:

std::string filePath = "/tmp/downloaded.exe";
std::string::size_type startPos = filePath.find("/tmp", 0);   // the "zero" means start from beginning
std::string::size_type endPos = filePath.rfind(".exe", filePath.size() - 1);  // search from back to see if it ends in ".exe"
if ((startPos == 0) && (endPos == filePath.size() - 4))
    // fits the pattern.

Well, yes, that looks a lot more cluttered. Let’s see if we can fix that if we know what we’re doing. Here’s my attempt:

std::string filePath = "/tmp/downloaded.exe";
if (filePath.find("/tmp") == 0 && filePath.rfind(".exe") == filePath.size() - 4)
    // fits the pattern.

Is this so much worse than the Java version?

As a STL afficionado, it does feel iffy to use integer indices to represent string positions, instead of actual iterators. A simple remedy for this would be to use std::search instead. If we did that, we could write the prefix test as follows:

std::string filePath = "/tmp/downloaded.exe";
std::string prefix = "/tmp/";
if (std::search(filePath.begin(), filePath.end(),
  prefix.begin(), prefix.end()) == filePath.begin())
    // fits the pattern.

Choose whichever you find more readable. The only major flaw we still haven’t dealt with is that I have to compute where the “end” string should begin if it is a suffix of filePath (and at the moment, I hardcode the length as 4. I could (and should) of course have taken the length of the actual string instead.

Alternatively, I could of course have gotten creative with string reversal: We could have said “when reading the string in reverse, do we find the reverse of ".exe" at the beginning?”, which could be implemented as follows:

std::string filePath = "/tmp/downloaded.exe";
std::string suffix = ".exe";
if (std::search(filePath.rbegin(), filePath.rend(),
  suffix.rbegin(), suffix.rend()) == filePath.rbegin())
    // fits the pattern.

Ok, perhaps that’s not more readable, but it avoids the need to determine the length of the ".exe" string, and when reading over it, the code is fairly logical: Perform a search (std::search) starting from the “reverse” beginning (rbegin) of filepath and ending at the “reverse” end (rend) of same, looking for the sequence that starts with the reverse end of ".exe", and ends with the reverse end of same. Is the position found equal to the reversed beginning of filePath?

Either way, if we buy into the STL mindset, then we gain a whole new advantage: std::string is extensible. The STL relies heavily on non-member functions to define the interface of a class. There is nothing to stop us from defining a non-member function ends_with() which, using one implementation or the other, checks whether a string ends with the given substring. I have already shown how we can, in one or two lines of code, perform a check for “begins with” and “ends with”. If we do the right thing, and wrap this functionality in small non-member helper functions, then we could simply use them like this

std::string filePath = "/tmp/downloaded.exe";
if (begins_with(filePath, "/tmp" && ends_with(filePath, ".exe")
    // fits the pattern.

To a Java programmer, this would be some kind of capital offense (it’d also be flat out impossible, because Java doesn’t allow non-member functions), but to a programmer used to the STL, this is idiomatic. The STL is designed to prefer non-member functions where possible. We’re used to them, and so extending std::string’s interface in this manner comes naturally.

Most likely, though, we prefer my first version. And while it’s a bit more verbose than the Java equivalent, every part of it is pretty easy to understand. find does exactly what you’d expect, and there’s no weird “if the comparison returned 0, it succeeded” check. Instead, the result of the search is compared against filePath.begin() which, to me at least, seems very obvious: we are checking if the found occurrence is at the beginning of the string, and likewise for the second check, we test whether the found occurrence is 4 characters before the end of the string.

It is certainly better than his so-called STL implementation. It’s not significantly worse than the Java implementation, and while he doesn’t show an implementation using MlfString, I’m willing to bet a few dollars that my version is cleaner than that as well.

Since I don’t have the source code for his class, the best I can do in order to provide a relevant comparison is to implement the same functionality without using std::string. So here’s the C version:

const char* filePath = "/tmp/downloaded.exe";
if (strstr(filePath, "/tmp") == filePath && strstr(filePath + strlen(filePath) - 4, ".exe") == filePath + strlen(filePath) - 4)
    // fits the pattern.

Perhaps I’m biased, but I think this is ugly and unintuitive. Let’s run through a few of the reasons:

• strstr isn’t a very obvious name. True, I know that it searches for the first occurrence of a string within another string, but would you have guessed that from the name? Recall that he just threw a fit over the name “OutputIterator”, so he’s clearly concerned about good naming conventions.
• while the the first strstr call is fairly straightforward (we search in filePath for the string "/tmp", and see if the result is a pointer to filePath itself, the last part, at least, requires intimate knowledge of how C-style strings work. Comparing the result against filePath only makes snse because filePath isn’t a string, it is a pointer to a char, and by convention, it is a pointer to the beginning of a sequence of characters that we’d like to treat as a string. by contrast, the STL example clearly compared against filePath.begin(), which makes sense just from reading the code, even if you’re not familiar with the string class.
• and the second call is where it gets hairy. Now we don’t just search for a substring within filePath, but we explicitly search within the string found at filePath + strlen(filePath) - 4: that is, in the last 4 characters, because otherwise, we might get find an early occurrence of the substring, and get the wrong answer to our query.

3. STL Encourages (Lures?) Programmers to Use Very Complex Data Structures

And here, it honestly becomes hard to see what the author is even driving at. I find it hard to imagine that anyone could seriously claim that “giving the user access to bug-free implementations of commonly used data structures is a bad idea”, but that seems to be what he suggests. And this is only moments after saying how much nicer Java is. Consider how many complex classes Java encourages/lures programmers into using. If he objects to a standard library providing pre-rolled functionality, then C++ is an odd place to start. Why doesn’t he object to Java or .NET, both of which offer standard class libraries hundreds of times larger? Why doesn’t he object to Python which contains practically everything in its standard library?

I generally assume that those reading and using my code are going to be reasonably well qualified. I imagine that they probably know their data structures, and will choose to use the one that makes sense. And I think it is a good thing for a library to cater to those who actually know how to use it, because those who don’t will manage to write bad code no matter what I do. They’re a lost cause, so why worry about them? If I can just give the qualified programmers the tools they need to write sound code, then I feel I have done a good job.

And the STL offers qualified programmers such commonly used data structures as linked lists, dynamic arrays, sets and a map/dictionary mapping from objects of some key type T to objects of a value type U. A programmer who doesn’t know when to use these has much bigger problems than the STL.

And then he makes the claim that…

If a programmer will have to spend 10 minutes writing their own linked list, they will make sure it is as simple as it can possibly be

which may be true, but if a programmer spends a mere 10 minutes writing their own linked list in C or C++, then

1. it will be buggy, and
2. they’ll be using the absolute worst data structure ever invented. There is hardly ever a reason to use a linked list. It does not allow random access, it requires an absurd number of memory allocations, and it completely thrashes your CPU’s cache.

Of course, the second point could be considered a premature optimization ¹, but the first one is unforgivable. Who in their right mind would, when choosing between reusing a well-tested and highly reliable class which can be accessed in a single line of code, and writing their own ad-hoc implementation, choose the latter?

Finally, we have a screenshot of where one of his coworkers found an instance of them using the wrong data structure. Where they use a list of pairs (which, by the way, even if it had been necessary, looks like something you’d only write if you didn’t know std::map existed) they just needed to loop over some other data.

Well, duh. I’m not sure how the STL is to blame for that. I’d have blamed the programmer who thought “I need a list of pairs here”. The code wouldn’t have been any better if he’d implemented his own linked list. The problem here isn’t that the STL makes robust and useful data structures available. It’s that a programmer chose to use them when they weren’t a good fit for the problem at hand.

And finally, he shows us that the code fails to compile, and asks us to decipher the error message, once again, of course, blaming it on the STL.

The only problem is, this is nothing to do with the STL.

One of the awkward facts of the syntax of C++ templates is that if you do something like foo<bar<baz>>, the compiler will fail to parse the code. It won’t see the >> as “end of parameters for the bar template, followed by the end of parameters for the foo template, but instead assume that it is operator >>.

Yes, that’s awkward. And yes, it is to do with templates, the other of his pet peeves. Luckily, C++0x, due to be standardized this year, fixes this, allowing >> to be parsed as you’d expect.. And while the issue will exist until then, it is certainly nothing to do with the STL, and the compiler actually offers us a pretty easily readable error message. It explicitly tells us that it found a >> instead of the > it expected.

Finally, of course, I’ve been itching to point out one more problem with this rant. He hates the standard library string class, but std::string is not part of the STL. It was added to the standard library separately, and received some last-minute polish to make it interact better with the STL, but it was not part of the STL — this also explains why it has a find method which doesn’t return an iterator. And funnily enough, that is why many C++ programmers, myself included, actually agree with the author that the std::string class is too complex. It should have been much simpler and more streamlined, like the “true” STL containers. std::vector doesn’t have 5 different overloads of a compare function which is a member for no reason, and uses a surprising and unintuitive return value convention copied from the C standard library’s strcmp. std::string is overengineered. Not because it’s part of the STL, as claimed in the article claims, but because it is not. Because it was added by people who hadn’t yet realized the elegance of the STL.

So in summary, yes, STL code sure is ugly when the person writing it doesn’t know what the STL is, and doesn’t know how to use it.

Does that surprise you? The same thing can be said for Java code, PHP code (although PHP code tends to be ugly no matter who writes it), Python code, or code written for any other language or any other library. I think the correct conclusion here is not “STL sucks”, but rather “If I try to write code using a library or language I don’t know how to use, the result is going to be messy”. But it is much more comforting to blame the tool, isn’t it? And so we get people hating some exceedingly elegant and usable parts of the C++ language because they themselves never bothered to learn how to use it.

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types.
I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms — you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work. — Alexander Stepanov

This post is an attempt at extracting something coherent from a series of comments I recently left on a StackOverflow question about “good design” (in what’s quite clearly an object-oriented context). The person asking the question has been gracious and patient enough to deal with my countless comments repeatedly pointing out that he’s doing it wrong, which would probably have driven a lot of people mad.

Many people have come up with many varied criticisms of the object-oriented programming paradigm. My problem with it is not new — in fact it is pretty much exactly what Stepanov pointed out in the interview I quoted above (and which is definitely worth reading in its full length). The only real difference is that he is an extremely intelligent mathematician, and I’m… not. So I’m not able to express it as concisely. But then, on the other hand, maybe my take on it will be easier to swallow for others who also aren’t hyper-intelligent mathematicians.

When we design software, what we really design are processes. A program is, without exception, a piece of code that does something. Code which does nothing does not constitute a program. (even a program such as this does something: int main() { return 0; }: it takes up several CPU cycles. It spawns a process that, if I’m quick, I’ll be able to see in Task Manager, ps or top. It enters the main function, after running all the CRT startup code. And what’s probably the most important property: it compiles and runs with no errors, giving us a solid starting point for further development. It does something, just nothing very interesting.

A webserver is not “something which has an HTTPListener object”, it is a process which given a string containing a HTTP request, produces a HTTP response. A compiler is not “something that has a Parser class and a Lexer class and an Inliner class and an ErrorMessage class”. It is a process which, given a program written in one language produces an equivalent program expressed in another language (or an error message). The parser doesn’t matter. But the parsing does. A parser by itself doesn’t do anything. It is no help to us. It only becomes useful if it is utilized in the process of parsing the supplied source code.

But OOP often becomes an exercise in designing code that does nothing.

The StackOverflow question that triggered this was about how to come up with a good design for a system which runs in a “car” and controls some of its components. Not a car that does anything in particular, just a car. A car which has an engine and a few other components, but which has no purpose, and are not associated with any process.

So my rather snarky, but accurate and concise, suggestion for a good design was this:

class Car {};

the above perfectly models a car which does nothing. In fact, I can extend it without writing a single line of code too. Here I create a BMW:

Car myBmw;

here I create a Land Rover:

Car myLandRover;

and I can represent electric cars, hybrids, tanks and trucks too, in the same way. Because our requirements don’t specify any processes, because our data model is completely inert, I don’t need to further distinguish between different types of cars.

This design is even suitable for “a system which runs in a car and controls various components of it”, which is a more verbose way to express “no requirements at all”. I can run this code in a car, and it will control every component of the car, provided that the components don’t actually have to do anything (and they don’t, because the specifications don’t say anything about we plan to do with the car that we’re controlling. Until we do something with the car, controlling its components is extremely simple. And if there is nothing we wish to do with the car, then any design will work.)

And yet such examples are always what OOP “gurus” talk about, what’s used to teach students, and for some reason, most people seem happy with this. OOP programmers¹ think such models of cars or animals are the most obvious things in the world. They sincerely believe that there is such a thing as “a good model of a car”.

There isn’t. Well-designed software is dependent on context. A good design for “a car” depends on what we want to use the car for. It depends on the processes and transformations we wish to put it through.

Say we’re building a racing game. the big dirty truth is that we’re not really interested in the car.

What matters is the data transformations that we wish to apply: it is the racing, not the car, that’s important.

Given information about the track we’re driving on, as well as position, heading, speed and input from the player, we wish to compute a new position, heading and speed for the car.

Of course a variety of properties and characteristics of the car the player is driving influence this transformation as well: perhaps the game models grip, acceleration, weight, shape/size (for collision detection), and let’s throw in manual vs. automatic transmission as well. All of these are inputs to our algorithm, whose output is a new state for the player’s car: it may have moved further along the track, it may have taken damage, or it may be spinning out of control. But the racing game doesn’t really care about the car. It cares about all these inputs which control the process of racing.

In fact, we may not even need a Car class (just like we probably won’t need a Game class). Or we may have several: one for use in the process of drawing the player’s car on the screen, one which represents the process of “driving a car” (when I drive a car, I can control the car radio, I can turn the steering wheel, I can start and stop the engine or change gears), and one which models the process of moving through the world, updating the car’s logical position in the world, reacting to physical forces and to any obstacles that I may accentally collide with.

But this is just one possible representation of a car. If we were designing software to control a car (because a car contains an awful lot of computers these days, and much of what makes it go is automated), then the process we wish to model is completely different. We may no longer care about the car’s position, for example (hopefully the driver keeps track of that), but the heating in the seats needs to be kept in check, we need to verify that the passengers have fastened their seatbelts, we need to respond to the drivers’ inputs, we need to ensure the engine keeps running. We need to control all the “cold start” magic that saves the driver the trouble of having to leave the car and turn a handle to start the engine. We have to listen for wireless signals from the little key thingy you click on to remotely unlock the doors and disable the alarm, and we have to react when we receive the “unlock” signal.

In this case, I almost certainly wouldn’t have a Car class; after all, what would I use it for? the entire program is supposed to be in a car already, so every line of code is conceptually already part of the car. I won’t have any code that’s outside the Car class. I’m modelling a car, but none of the processes I’m interested in require an object that represents “the car” as a whole. One process might require information about the fuel tank as an input, and one might provide commands for the car radio as an output, but none of the have “a car” as an input, and none of them produce “a car object”

In both cases, an OOP programmer would say that we are “designing a car”. And in both cases, I suppose that’s true. But hopefully, it is also obvious that we arrive at completely different designs, depending on what program we’re writing. And neither of them look like the traditional “design a class hierarchy for modelling cars” exercise, which would have been a terrible design in both cases.

So what does this tell us? Bad design may be universal (it’s easy to come up with a design that is bad in every context), but good design is not. Good design depends on the context. A good design is a design that satisfies the criteria imposed by the use cases for the design. Is it supposed to be used in a racing game? Then a certain kind of design works well, and is therefore “good”. Is it for controlling the internals of an actual car? Then a completely different kind of design works, and then that design is “good”. Is it for car manufacturers to design and evaluate car prototypes? Then the software design is going to look entirely different again. And if the context is simply “be a good design for modelling a car”, then I maintain that class Car{} is both the simplest, cleanest and most flexible design. It satisfies every rule of OOP (it is perfectly encapsulated: you have absolutely no way of mucking around with the internals of the class; it is polymorphic, even without having to resort to virtual methods and inheritance, this simple class can represent any car you care to think of, and so on). The only weakness of this design is that it doesn’t actually participate in any interesting processes. We can’t use it to do anything with the car. Oh sure, we can manipulate the car itself easily:

Car myCar;
// the car's engine is now running
// the car's left door is now open
// here, I refuel the car

and in fact this design allows an amazing level of extensibility: no matter what operation you wish to perform on the car, you don’t actually need to write a single line of code. You can merely decide that the car is now in the desired state. If you like, you can add a comment, like I did, clarifying this to the next maintainer of the code.

But while we can modify and extend the car itself easily, we can’t use it in a program that does anything. It is useless in my racing game, it is useless for controlling the internals of a car, and it is useless to car manufacturers. It doesn’t do anything, it just sits there. But that’s what we were asked to produce: a model of a car, which is “good OOP”, which is extensible and so on. It was required to be all these things. It just wasn’t required to be useful.

When teaching children to read, we don’t ask them to “come up with something to read”. We don’t encourage them to “write something, and then read it”. Architects are taught how to build houses by studying the properties of actual houses, not by drawing a house, and then trying to learn from that drawing.

And yet OOP students are taught that the way to learn “good design” is to, well, design the code for some problem they just made up: design a class hierarchy for cars; design one for farmyard animals. And it doesn’t work. The only way anyone is going to learn “good design” (to the extent that it is something that can be learned) is by studying design “in the wild”. Just like children have to read text written by others, and architects have to look at houses already built by others.²

And that is OOP in a nutshell: as Stepanov pointed out, saying “everything is an object” may be true, but it’s not very interesting. I just created a car object, I just can’t use it for anything, because it’s really not the object in itself that’s important: it’s the process we want it to participate in.

Functional programming avoids this pitfall: it focuses explicitly on the functions, on the manipulation and transformation of data. Functional programming is all about taking an input and producing an output. If a functional programmer is required to “design a car”, he won’t make a useless and inert “car” class which doesn’t actually do anything. Instead, he will program the functionality required. If he needs to write a racing game, he will write functions which, given the current state of the car and the input from the player, produces an updated car state. He will write code that does something, which solves a problem (in this case, the problem of moving a car in a game in response to the player’s input)

Generic programming also avoids the trap (perhaps obviously, since it was invented by the Alexander Stepanov whose criticisms of OOP I quoted), by focusing on the algorithms and the data transformations, and only then coming up with a suitable interface to describe the data. For a racing game, I need to be able to race. That’s the process I want the program to carry out. And as I code this, I will eventually get to the point where I need to express the car “being raced”. And then I have the information needed to come up with a “good design” for a car.

Even plain old procedural programming got it right: the important parts are the procedures that you write to do things to your data. Without them, your program just isn’t very interesting.

So a good design is not actually about the car, it is about the processes we wish to perform on it. That is true, no matter what we are designing.

Take something as simple as the int datatype. It generally works pretty well. Is it well designed? I suppose so; it’s extensible (I can define new operations that work on an int), it is easily reusable and so on.

But there is nothing universal about it. It uses a base-2 representation internally, which makes good sense in the context in which int is typically used: efficient integer computations on a von Neumann computer. It has some obvious limitations (it can’t store numbers above a certain size, for example), but it usually works for what we need it to do, and it is efficient and compact.

So why don’t we use it in the “real” physical world? Why do we use the decimal system instead? Mainly because we (well, most of us) have 10 fingers, and so that makes it a bit easier for us to learn to count. So in that context, a good design for an “integer datatype” uses the base-10 representation.

And then again, perhaps it doesn’t. If you asked me to design a “good” integer for real-world use, I think I’d go for base-8. That does limit our range a bit (If I count naively on my fingers, I can only get to 8, instead of 10), but on the other hand, 8 is a power of two, which gives us a whole lot of other benefits: it makes it easier to convert to and from a lot of other bases, for example, and even for counting on our fingers, I believe there are significant benefits. It frees up two fingers which we can use as a “carry bit”, for example, and then a “temp” bit for storing other information related to what we’re counting, but not part of the number itself (or I could use it as a sign bit, allowing me to count negative numbers too). Or we can use both of the two remaining fingers to represent the second digit, and then we’re able to count all the way up to 27 on our fingers.

I think that would’ve been a better design when initially designing our number system. But today, of course, the context is another yet again. Now backwards compatibility is a concern. Switching to a base-8 system would confuse 6 billion people, which is probably a non-starter. So in the situation we’re in today, base-10 is, after all, the optimal design. I just wish I’d been consulted when it was initially decided on as a standard.

Even roman numerals were a good design choice for a certain context: it’s good enough for simple counting, which was what most people needed, even though it fell flat at more advanced mathematics (which most people at the time never needed). And it didn’t involve inventing or learning any new symbols. If you knew the regular alphabet, you also knew the symbols necessary for writing numbers.

Just like with the cars, the “goodness” of a design decision depends on the context in which it is intended to be used. It depends on the processes we wish to perform. Binary is a good choice in a computer because we wish to perform integer arithmetic efficiently, and because it doesn’t cause significant confusion for users of the program. Decimal numbers are fine for counting on our fingers, which was one of the things we required our “real-world” number system to support when we came up with it.

The design is about the algorithms, the processes, the transformations. The representation of the data is a consequence of those decisions.

So, am I saying that objects are useless, or even harmful? No, they’re just not important. They’re a convenience. They can do some useful things, like enforcing constraints and invariants so that we can easily keep our data in a consistent and valid state. Designing classes just won’t make our program do anything. Objects are handy enough to have around. But it’s absurd to “orient” your program around them, just like you never see “brick-oriented architecture”. Architecture is about making a house that serves the purpose of a house, and bricks are just one of many materials that can be useful in getting there. But an architect doesn’t start from the brick. Bricks aren’t interesting, they just lie there, waiting to be used for something. A brick only becomes interesting when it is used for something: when it participates in the process of keeping out the cold, or the process of creating an aesthetically pleasing facade, or the process of keeping the building from collapsing.

Classes are, as Stepanov pointed out, something you design at the end, when you need to create data structures to pass through your algorithms. Once we have the algorithms that we want our program to perform, we’re going to need to define data structures that they can process. And here, objects are very handy. If I use a class to represent my car, then I can make sure that a car always has 4 wheels. I can ensure that the amount of fuel in the tank is never negative, and so on. I can enforce a lot of invariants that makes it easier to reason about the rest of my program. But the program is not “about” my car class. It is not “object-oriented”. It is oriented around the process I want to carry out on the car.

The question of “how do I represent a car” is impossible to answer until I know what I want to do with the car. Once we have that information, we can, if we wish, apply all the OOP teachings to come up with a suitable representation of this particular bit of data. And then we can evaluate whether this is a “good design” for a car by looking at how well it works with the algorithms and processes that make up the functionality of the program.

I’m fine with that. It’s often annoying that we have to be so paranoid, that we so often have to double-check that our code not only compiles, not only passes our tests, but also avoids the dreaded Undefined Behavior (where the behavior is not constrained by the standard), but you get used to it. And all in all, being precise and specific when talking to a compiler is probably not a bad habit to get into, regardless of which language you program in.

However, every once in a while, people try to carry the same level of pedantry over into discussions about C++. In particular, a certain subset of C++ experts regularly complain that nearly every C++ programmer has their terminology mixed up. And that annoys me. If 99.9% of all C++ programmers use a term in one specific way, then even if it’s not supported by the ISO standard, perhaps we should just accept it. Yes, if you’re a compiler, it would introduce an ambiguity, but we’re not. We’re human beings, and we’re good at dealing with ambiguities. And while using the term correctly would theoretically eliminate any ambiguity, in practice it would cause a lot of it instead: today, we can guess with 99.9% certainty that people use the “incorrect” definition when they use the term. If we tried to make everyone use the term correctly, we’d be unable to guess at which meaning people actually intend to use.

The term in question is, of course, the STL. The Standard Template Library, developed by Stepanov in 1994, made available by SGI and finally adopted with some changes and some parts left out by the C++ standards committee into the C++ language in 1998.

Strictly speaking, the name “STL” refers to the SGI library (and, some would argue, to the language-agnostic idea for a library gradually developed by Stepanov before he implemented it in C++). Strictly speaking, the C++ standard makes no mention of a “Standard Template Library”. Strictly speaking, “STL” refers to a 15 year old library that no one would ever dream of using, because we’ve got an up-to-date near-copy in the C++ standard library. Strictly speaking, no one would ever want to use the name “STL” today.

And yet even C++ experts like Scott Meyers and Herb Sutter use the term incorrectly (unless we accept that Sutter offers courses in a 15-year old obsolete library rather than effective use of the C++ standard library)

And of course, the best part is that if we all were to start using the term correctly, we have nothing to replace it with. We don’t have another name for “the STL-derived parts of the C++ standard library”. We can say “the C++ standard library”, which, apart from being an extremely verbose name, also covers all the other parts of the standard library.

So really, is it worth it? What purpose does it serve to try to convince every C++ programmer in the world, to stop using the name “STL” to describe “the parts of the C++ standard library which look suspiciously like the STL”? We free up the name so we can use it to name a library that we virtually never need to mention. And we get to be wonderfully pedantic when talking about the C++ language, just like we already are when talking about C++ code. But we’ll also cause a lot of confusion, making it needlessly difficult to discuss one of the most commonly discussed areas of C++, because 1. it no longer has a simple name, and 2. when people use that name, we no longer have any idea what they’re referring to. They could be a “reformed” well-behaved C++ programmer, using it to refer, for some reason, to a library no one has used for the past 10 years, or they could be a rebellious troublemaker abusing the name to refer to a subset of the C++ standard library.

So, an appeal to all those C++ experts who think the world would be a better place if we all used the name STL correctly: stop it. Sit down, take a deep breath and accept and assume that the name is going to be used incorrectly by virtually everyone virtually all the time. Don’t pretend to be confused when people say “STL”, because you’re not. The ambiguity exists only on a theoretical level. In practice, no one ever wants to talk about the SGI library, and if they do, they will make it clear from context.