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).

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!

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.

Many people are in love with the Singleton pattern. Others — a small minority, I suspect — consider it a mistake, an anti-pattern, or something that was only ever included in the Design Patterns book as a lifeline to procedural programmers who couldn’t really figure out this OOP thing.

I won’t pretend to be half as clever as all the people who have already written about the problems with singletons years ago, and I don’t think I have anything new to bring to the table. But it is a pattern I learned to loathe years ago. (Singletons do sound attractive when you first hear of them. But they pale a bit when you end up having to tear up and rewrite half your code just because all your singleton classes start revealing their shortcomings) And for a long time now, I’ve tried to convince other programmers that Singletons have some serious problems. Recently, it seems like I’m even getting noticed for it among the users of StackOverflow.

First, oneuser posts an answer to one question, and I comment with a mild disagreement, and the discussion goes on for a few more comments. As singleton rants go, this one is pretty mild, and I don’t really think about it any further. Then, a few weeks later, I discover his blog and this post. Wow! A convert. A person I know to be a smart and a knowledgeable programmer has changed his mind in response to something I said… I’m flattered.

And today, I noticed another question being posted, which had both Boost and Singletons in the title — how could I resist? Two subjects I enjoy talking about, even if the things I say about them are very different. Surprisingly, the comments there already mentioned me, and some of my earlier answers regarding singletons. Should I be flattered or worried that people have started bringing my name up when discussing Singletons?

Anyway, one of the comments also suggested I write a blog post describing my argument in detail. So I will. I’ll even throw in a redirect link from http://jalf.dk/singleton, to make it as easy as possible to find.

Two wrongs don’t make a right

There are a lot of problems with singletons. In fact, it’s surprising that so many people still consider the pattern useful, when it is afflicted with so many weaknesses and flaws. However, for now I will single out the two that I feel are the most fundamental: not just problems with how a singleton works, but with what they’re trying to achieve:

A singleton, as defined by the Gang of Four, combines two properties:

• it guarantees that exactly one instance of an object exists. While that one instance is typically created lazily, so it doesn’t technically exist throughout the entire application’s lifetime, it always seems to the programmer as if precisely one instance exists, and
• it guarantees global access to this one instance.

Let’s pick those apart a bit. The last one is easiest: it is, by now, fairly common knowledge that global state is bad. We don’t like global variables, we don’t like static class members, we don’t like anything that makes it harder to isolate bits of our code. Dependence on global state causes a lot of problems: it hurts parallelism, as access to global mutable state generally has to be serialized through the use of locks. It makes dependencies harder to detect and control (any function might silently decide to access our singleton. The function signature says nothing about this, so we have to read the source code of the function to determine if this is the case. And because it is so convenient to always just add a reference to a singleton, we tend to do it a lot. When you have a singleton, you quickly end up in a situation where three out of four classes depend on it. How did that happen? Why, logically speaking, do so many classes need direct access to the database? Or the renderer? Is that good design? Not only is this messy, it’s also painfully hard to fix after the fact. Once we have these dependencies on global objects everywhere, that’s a lot of code we need to change to eliminate the global. Almost every class will be impacted by the change, and a huge number of functions have to have their signatures modified to take that extra parameter replacing the global. Or even worse, the function has to be completely rewritten to eliminate the need for whatever service the singleton provided. The more globals you have in your project, the more your dependency graph starts resembling spaghetti. And the harder it gets to clean it up.

It hurts reusability, as code taken from one project and inserted into another may break because it depended on globals not present in the new project. It hurts testability partly for the same reason, a unit test testing a class must suddenly provide a number of globals as well just for the code under test to compile, but also because global state makes tests less deterministic. One test might change the state of this global, affecting the outcome of the next test to run.

Globals are bad for a lot of reasons. They have their uses, no doubt about that, but we should be suspicious whenever the solution to a problem involves global data. It might be the best solution, but often, it is more trouble than it’s worth.

The other point is more subtle. Why do I object to a class enforcing that “only one instance may exist”? It’s really just common sense. As the Agile movement tells us, we don’t really know what our code is going to look like tomorrow. Over the course of development, we have to adapt to changes, modify our code, revise decisions already made. Why put roadblocks in front of us? Why make it harder to adapt to unforeseen changes or requirements?

Today, I might think that I need only one logger instance. But what if I realize tomorrow that I need two? That’s not so far fetched. We may have one log we write ad-hoc messages intended for debugging purposes, solely to be read by developers, and another formalized log, where structured messages are written when predetermined events occur, so that the application can be monitored in production. Sure, we could define the two as completely separate classes, and then we’d only need one instance of each (but then we’d start duplicating code). Or we could use the same log instance to write to both logs (but then the logging code would become more complex, having to interleave two separate and non-overlapping logs.

Once we’ve accepted that an application may need more than one logger, shouldn’t we do ourselves the favor of ensuring that our loggers can be instantiated more than once, just in case it turns out to be the right thing to do? We’re not even adding any complexity, there’s no cost associated with this. On the contrary, we’re removing significant complexity. Thread-safe singletons are surprisingly hard to get right. Dependencies between singletons are tricky and circular ones can cause them to blow up in all sorts of fun ways. And let’s not even get into how to handle anything our singletons might do while the application is shutting down. What if the database singleton tries to write a simple “goodbye” log message to the log singleton? What if the log singleton got destroyed before the database one? Ouch.

Singletons are hard to write and hard to use. Removing them only simplifies our code, so if it also enables us to better adapt to unforeseen requirements, why shouldn’t we remove them?

Not convinced? Let’s think of some other examples then:

• the application configuration should be a singleton, right? We obviously can’t have more than one of those! Wrong. We can. We often do. Think about what happens when the user opens the “Options” screen and modifies the settings. During that time, two sets of settings exist: the “applied” settings that are currently in effect, and the “speculative” ones, currently being picked out by the user. Once he clicks OK, the speculative changes should be applied, replacing the ones that were previously in effect. But until then, we have two sets of settings to maintain.
• a database connection pool then! If we have more than one pool of connections, we can’t efficiently share them! Correct, but perhaps we don’t want to share them. Perhaps I want to ensure that library A has one pool of 10 connections available to it, component B has a smaller pool of 3 connections, an components C, D and E use the global pool with however many connections it supplies. That would ensure that no matter the number of threads running in component B, it’ll never starve out other components trying to access the database. It can never hold more than three connections, leaving room for other components. Of course, in the common case, we do want all connections to be shared in one single pool. But perhaps not always. So yes, there should probably be a globally accessible default pool available. But why shouldn’t it also be possible to define new local pools if the user deems it necessary? Why limit ourselves to one instance?

And even if you do come up with some case where we absolutely must never have more than one instance, where it would make the sky come crashing down on us, consider testing. Consider that each of your unit tests should set up the environment it needs, and run within that environment, in isolation from other tests. That means that every test should create its own logger instance, or database pool instance, or whatever else our singletons are doing, just so it can avoid being polluted by stateful changes made by earlier tests. Each unit test for the Direct3D renderer should set up its own renderer object. Each physics simulation test should initialize the physics engine first, and shut it down again after use. Singletons don’t easily allow that. Sure, we can extend them with explicit Create() and Destroy() methods, but then our abstraction is starting to get leaky. We can no longer assume that precisely one instance exists, because we might have just destroyed the one that existed.

The “exactly one instance” guarantee removes flexibility from our code that we may need, in order to enforce a constraint that we definitely don’t need. Where’s the harm in allowing the user to create more than one instance if he decides to?

C++ programmers are familiar with std::cout, the standard output stream. Funny thing about this, it is a simple global object. We can obviously never have more than one standard output stream. But we can have more than one stream. The standard library just initializes one of them to point to the standard output, and saves it as a global variable. We don’t need it to be a singleton, we don’t even need it to be a static class specially defined for the purpose. We just need a stream, defined somewhere where it’s globally accessible.

True, a sufficiently stupid programmer could create a new stream when he intended to write to std::cout, and true, a singleton implementation would have prevented that. But is it worth it? When was the last time you saw someone accidentally invoke std::ostream() << "Hello world";, when they intended to write std::cout << "Hello world";? It’s not the most common typo I’ve seen.

We don’t need to prevent multiple instantiations. If we want only one instance, we just instantiate the class once, and refer to that instance whenever we need it, end of story. We don’t need the compiler to slap us over the wrists if we do create multiple instances, because we never do so by mistake. If we do it, it’s because we have a reason. It’s because our initial assumption that only one instance was needed, turned out to be wrong!

So there you have it. A singleton combines two negative qualities. It takes the “you can never create a second instance of this class” constraint, which hardly ever makes sense, and even when it does, does not typically need to be enforced by the compiler, and combines it with a global object, giving us all the downsides of both!

Two wrongs don’t make a right. Not even if they were described as a good idea by some guys 15 years ago. They’re still no greater than the sum of their parts: two wrongs. One bad thing combined with another bad thing, creating a very bad thing.

Too many programmers rely heavily on singletons to solve a problem they never had. They never needed a compile-time guarantee that multiple instances of a class can never be created. They just needed one instance to be created.

Sometimes, we do need globals, yes. In those cases, make old-fashioned globals. Use static class members, or if the language allows it, global (non-member) objects. Or use the Monostate pattern, or whatever you feel is the cleanest solution. But remember that the problem you’re trying to solve is “enabling global access to this data”. No more, no less. You do not want a solution which sneaks completely unrelated constraints and limitations in through the back door.

And while I can’t personally think of many cases where this is true, you might also run into situations where it is truly necessary to prevent more than one instance of a class from ever existing. Again, I can’t think of what situation this might be, but I won’t rule out that it can occur. If it does, then enforce that constraint alone. But don’t go around providing global access to the object as well. Whatever specialized purpose your “one instance only” class serves, it’s highly unlikely that everyone should be allowed access to it. So don’t make it a global.

Most of the time, your classes should have neither of these attributes. Sometimes, rarely, they may need one of them. But the singleton pattern imbues the class with both properties, and that is just a plain bad idea.

If I had to pinpoint one thing that marked the difference between a skilled and an unskilled C++ programmer, it would be “do they understand RAII”. Many people don’t, hence this post.

RAII is, apart from being badly named, one of those deceptively simple concepts that you think you understand when you first hear of it, think “well duh, that’s obvious”, and then proceed to write code as usual, because you just don’t see how widely applicable it is.

But let’s get the name out of the way first. RAII stands for “Resource Acquisition Is Initialization”. And if you’re not already familiar with the idiom, then this has told you nothing at all. If you did know about RAII in advance, then you can, when you stop and think about it, kind of see how the name relates to it… vaguely… sort of.

What it actually means is simple: Resources should be managed by classes. When the class is initialized, the resource is acquired (hence the name). When the class is destroyed, the resource is released. And the lifetime of the object should exactly match the desired lifetime of the resource. That sounds obvious, and many programmers will (assuming they’re working in a language that has classes), say that this is what they always do.

Often, C++ developers think this just means “smart pointers. Wrap your memory allocation in a boost::shared_ptr and you’re done”. I see that as one not-very-often used border case though, rather than a typical example of RAII. So let’s take a step back instead.

The key idea isthat any kind of resource, not just memory, but file handles, sockets, database connections, or even more abstract resources like loggers or profiling timers or textures, really any concept or process which has a lifetime, should be mapped to an object.

Unlike the typical object-oriented line of thought which goes that “everything must be an object, because then.… well, everything will be an object, and your code will be better”, here we actually have a concrete reason: We want to use the object to manage the lifetime of the resource.

When I allocate memory with new, I have to deallocate it again sooner or later, with delete. (Or in C, with malloc() and free() respectively). And I have to make sure that this is done. And I have to make sure that it is not done twice. And that the object is not accessed after this is done. There are a lot of constraints we have to obey, all related to the lifetime of the resource. And this is why unmanaged programs have a reputation of leaking memory left and right. If we allocate memory, and it is to be used by a dynamic number of objects or functions all referencing the same allocations, which of the users is responsible for deleting it? And how do we know when it is safe to delete, when no users remain?

Ironically, most managed languages have not solved the problem. They have added a garbage collector (which yes, is very useful for a wide number of reasons), but that only solves one specific instance of the problem. It takes care of avoiding memory leaks, but it doesn’t avoid resource leaks in general.

The garbage collector ensures that this code won’t leak memory:

void foo() {
  SomeObject* obj = new SomeObject();
  bar(obj);
}

where without a garbage collector, we’d (at least without RAII) have to write code such as

void foo() {
  SomeObject* obj = new SomeObject();
  try {
    bar(obj);
    delete obj;
  }
  catch(...){ delete obj; }
}

In the garbage collected case, we don’t know what bar does, and we don’t need to know. It doesn’t have to delete the object. And neither does the foo function. So we have successfully dodged the problem of managing the lifetime of memory allocations. We haven’t really solved the problem though. We still don’t have any good tools to manage the lifetime. We’re just guaranteed by the system that it’ll last long enough.

In C++, this effect can be approximated using some kind of smart pointer¹.

Smart pointers allow us to write code like this:

void foo() {
  boost::shared_ptr<SomeObject> ptr = new SomeObject();
  bar(ptr);
}

and be sure we won’t leak memory. Of course, this solution isn’t perfect — reference counting is much more expensive than a good garbage collector, and if we create cyclic references, the objects will never be deleted, as the reference counts never reach zero. It is a decent approximation, but nowhere near as good and reliable as the garbage collector in managed languages.

But the problem shows up again if we use another type of resource. What if we’d opened a database connection instead? We’d have to write code such as this: (The following Java-like pseudocode is copied almost verbatim from this StackOverflow.com answer, courtesy of Martin York.)

void writeToDb()
{
  Db db = new Db("DBDesciptionString");
  try
  {
    // Use the db object.
  }
  finally
  {
    db.close();
  }
}

(And of course it gets even worse if db.close() can throw exceptions. Then we have to catch that exception, just to avoid it propagating out from the finally clause if we reached finally because of an exception being thrown in the try clause.)

The resource management problem still exists. We still have to wrap the code in exception handling just to make sure that the connection is closed as soon as we’re done with it. And we have to do this at every use. And it gets complicated fast.

Of course, .NET makes this a bit simpler:

using (Db db = new Db("DbDescriptionString"))
{
  // use the database object.
}

But the onus is still on the user of the class to ensure it is closed correctly. There is no obvious way to encode into the Db class that “once we’re done with an object of this type, the connection must be closed immediately”.

And in C++, smart pointers are no longer suitable solutions, since the resource to be managed is no longer a pointer allocated with new.

Instead, a more basic flavor of RAII comes to the fore:

void someFunc()
{
    Db db("DBDesciptionString");
    // Use the db object.
} 

Yes, that’s all. When the db object goes out of scope, at the end of the function, its destructor is called. The destructor internally calls this->Close() for us, so we don’t need to do it! We just have to trust the scoping rules of C++, which guarantee that destructors are called on local variables when they go out of scope, and on class members when the class is destroyed.

So in a sense, the key idea in RAII is simply that “resources should behave sensibly”. They should get copied safely if an assignment is made (or otherwise, assignments should be prevented), they should be available if their owning object is successfully created (if it can’t create the resource, it should throw an exception, aborting the creation of the object), and when they are no longer used, they should be cleaned up.

The C++ standard library class template std::vector is a wonderful example of RAII in action. The resources being managed by a vector are memory (the array allocated internally to hold the objects being contained in the vector, as well as the objects themselves. When the vector is destroyed, every object it holds must be destroyed too, and the array in which they were placed must be deallocated.

In the following examples, assume that a function foo is passed a vector of MyClass objects by value. We don’t know how many, if any, objects are stored in it, but since we are passed a copy of the original vector, we take ownership of it. It exists only in the function foo, and must be destroyed afterwards.

void foo(std::vector<MyClass> vec) {
  ...
 //  when we get to the end of the function, all local variables, including vec, 
 // are automatically destroyed by having their destructors invoked.
 // So no matter how many MyClass objects were stored in the vector, it ensures that they too have their destructors called.
 // And the vector also deallocates its internal array, leaving neither of its resources alive at the end of the function
}

void foo(std::vector<MyClass> vec) {
  throw std::exception("Oops");
  // as above, vec is automatically destroyed when we leave the function,
  // regardless of *how* we leave it. Even if we leave it because an exception was thrown and not caught.
} 

void foo(std::vector<MyClass> vec) {
  // other is constructed as a copy of vec. std::vector ensures that both of vecs resources are copied as well
  std::vector<MyClass> other = vec;
  // we now have two vectors, each owning a dynamically allocated array and a number of MyClass objects
  // and again, at the end of the function, both are deallocated cleanly
} 

void foo(std::vector<MyClass> vec) {
  std::vector<MyClass> other; // a second, empty, vector

  // perform an assignment, setting vec to be an empty vector
  // std::vector makes sure that if you do this, the resources previously held by vec are cleanly released
  // before copies are made of the resources held by other
  vec = other;

  // and so when the function ends, the MyClass objects originally held by vec
  // have already been destroyed, so their destructors are *not* invoked now
} 

As the above shows, vec owns its resources, and manages them tightly. Whenever a change happens to vec, it reflects this by updating its owned resources. If it is destroyed, it destroys its owned resources. If it is copied, it copies the resources it owns. If it is assigned to hold something else, it first destroys its existing resources. And so on. Nothing you do can bring it “out of balance”. It just works. That is RAII. Smart pointers are just convenient adapters turning raw pointers into RAII objects. But RAII is much more than smart pointers.

It is the broad and general idea that resources should be mapped to objects, so that the object can not be created unless it succeeded in acquiring its resource, and it can not be destroyed without also releasing its resource. This effectively saves C++ programmers from having to worry about resource management.

Take an example that’s guaranteed to cause pain without the use of RAII: Handling exceptions being through halfway through constructors. Say you have a class with multiple members which are initialized in its constructor. After the first member has been initialized, but before all of them have been initialized, an exception is thrown. Let’s use the following contrived example:

class Foobar {
  Foo f;
  Bar b;
  MyClass c;

public:
  Foobar() : f(42), b("hello world), c('a') {}
};

unfortunately, b’s constructor throws an exception. How to handle this? We know that in C++, partially constructed objects do not automatically have their destructors called. when the construction is aborted.

And since we want to avoid any resource leaks, we require that the following must happen: – a must have its destructor called (because a was successfully initialized before the error occurrd) – b must release any resources it acquired in its constructor before it threw the exception – c must do nothing. Its construction was not yet begun when the error ocurred, so it would be an error to attempt any kind of cleanup of c. – The Foobar object (the object pointed to by the this pointer) must ensure that the above, and nothing else, happens, and it must do so without relying on its own destructor (which won’t be called, as construction did not successfully complete).

And of course, pretending that only b can throw an exception may be a simplification over the real world. Perhaps every member could throw one from its constructor. Care to write a Foobar constructor which takes all this into account, providing enough try/catch blocks to correctly catch every exception that might be thrown, and release exactly the resources that have been allocated until then, and nothing else? A tall order, and an open invitation for bugs. And of course, it’d lead to a huge, bloated and error-prone constructor. It’d also prevent us from using the initializer list. We’d have to perform some kind of “safe” non-throwing default construction of both a, b and c before entering the constructor body, where exception handling is possible, and from there, attempt to perform assignments to bring the three members into the desired state.

In pseudocode, the constructor might look something like this:

Foobar() {
  a = new Foo(42);
  try {
    b = new Bar("hello world");
  }
  catch {
    destroy a;
    throw;
  }
 try {
    c = new MyClass();
  }
  catch {
    destroy b;
    destroy a;
    throw;
  }
}

Note that all this complexity is only necessary because we want to handle several different resources. a, b and c all contain resources that must be attempted acquired, and properly released if this fails. If there’d been only one resource, the job would have been much simpler. There wouldn’t be any point at which some resources have been acquired, and others have not. If we succeeded in acquiring that one resource, there’d be no risk of errors occurring afterwards, so we wouldn’t need complex conditional cleanup code. And if we failed to acquire the one resource, there’d be nothing to clean up — after all, the resource was never acquired!

So to keep down the complexity, the only safe way to define a class is to make it own at most one resource. And this one-to-one mapping of resources to classes is exactly what RAII is all about. If a, b and c had all been RAII objects, then the above code would work. Regardless of which members could or couldn’t throw exceptions. According to the rules of C++, we know that in the above case,

• the Foobar destructor (this->Foobar::~Foobar() will not be called, as *this was not successfully constructed.
• the a destructor will be called, as this member was fully constructed at the time of the error.
• the b and c destructors will not be called, as these members were not fully constructed at the time of the error.

So assuming that b’s constructor takes care of releasing any resources successfully allocated when the error occurred (the number of which, as pointed out above, should ideally be zero), we’re actually home free! What happens is exactly what we listed earlier as our goal. a has its destructor called, c’s constructor was never run in the first place, so it doesn’t have to do anything, and *this doesn’t have to do anything special in its constructor. All of its members take care of their own resources, so the number of resources managed by *this is zero!

We don’t even need to write a destructor for Foobar now, if all its members are RAII objects. Whether the Foobar object is partially or fully constructed, its members take care of themselves. That is the power of RAII. Once a resource has been mapped to a class, we can use it as much as we like, and even in very complex situations, and never have to worry about the resource being leaked. It is managed by its wrapping RAII object, and the C++ lifetime and scope rules ensure that this wrapper object gets destroyed when it goes out of scope