Where to find the state of ISO C++ evolution

After each ISO C++ meeting, I post a trip report update to my blog summarizing what’s new as of that meeting with a drill-down into some highlights. But wouldn’t it be handy to have an up-to-date summary scorecard with a snapshot of all proposals’ status to date? Indeed it would, and so today someone asked me in email:

I’m a software developer interested in forthcoming C++ standard. Are there any resources on the web where can I find
list of already accepted proposals as of the last meeting in Bellevue? I know that I can read the draft but I would like to have all new features in a list form.

Answer: Yes, thanks to the gracious volunteer efforts of Alisdair Meredith. Alisdair maintains the “State of C++ Evolution” paper, and posts updated versions before and after each ISO committee meeting. You can find the current one here:

For updates, just watch the committee papers pages where new batches of papers get posted every two or three months, including new versions of the evolution status paper and new updated working drafts of the next ISO C++ standard (maintained by our hardworking, and amazingly tireless, project editor Pete Becker).

Thanks, Alisdair and Pete!


1. Yes, Pete’s car has wheels. That’s not what I meant.

Quad-core a "waste of electricity"?

Jeff Atwood wrote:

In my opinion, quad-core CPUs are still a waste of electricity unless you’re putting them in a server. Four cores on the desktop is great for bragging rights and mathematical superiority (yep, 4 > 2), but those four cores provide almost no benchmarkable improvement in the type of applications most people use. Including software development tools.

Really? You must not be using the right tools. :-) For example, here are three I’m familiar with:

image Visual C++ 2008’s /MP flag tells the compiler to compile files in the same project in parallel. I typically get linear speedups on the compile phase. The link phase is still sequential, but on most projects compilation dominates.
imageSince Visual Studio 2005 we’ve supported parallel project builds in Batch Build mode, where you can build multiple subprojects in parallel (e.g., compile your release and debug builds in parallel), though that feature didn’t let you compile multiple files in the same project in parallel. (As I’ve blogged about before, Visual C++ 2005 actually already shipped with the /MP feature, but it was undocumented.)
image Excel 2007 does parallel recalculation. Assuming the spreadsheet is large and doesn’t just contain sequential dependencies between cells, it usually scales linearly up to at least 8 cores (the most I heard that was tested before shipping). I’m told that customers who are working on big financial spreadsheets love it.
imageAnd need I mention games? (This is just a snarky comment… Jeff already correctly noted that “rendering, encoding, or scientific applications” are often scalable today.)

And of course, even if you’re having a terrible day and not a single one of your applications can use more than one core, you can still see real improvement on CPU-intensive multi-application workloads on a multicore machine today, such as by being able to run other foreground applications at full speed while encoding a movie in the background.

Granted, as I’ve said before, we do need to see examples of manycore (e.g., >10 cores) exploiting mainstream applications (e.g., something your dad might use). But it’s overreaching to claim that there are no multicore (e.g., <10 cores) exploiting applications at all, not even development tools. We may not yet have achieved the mainstream manycore killer app, but it isn’t like we have nothing to show at all. We have started out on the road that will take us there.

Usability: Watch out for those non-errors that start with “ER”

Today I had a nice lesson in transaction codes. I did a happy little online transaction, and then the confirmation screen came up with what at first glance looked like an error. It startled me, until I read more closely:

Thank you. Your transaction has been placed and received by SuperMondoCorp.

Transaction Confirmation Number: ER6661234567

“Yikes!” thought I to myself, thought I. Then, “oh, the bolded confirmation number just starts with ER which only looks like ERR.” (And yes, the rest of the number did start with 666. I only altered the other numbers.)

I realize you can’t anticipate everything, but it is a reminder about usability. If the thing you draw the customer’s eye to on a confirmation screen can start with what looks like a negative confirmation, it’s not the greatest thing.

Effective Concurrency: Interrupt Politely

The latest Effective Concurrency column, “Interrupt Politely”, just went live on DDJ’s site, and will also appear in the print magazine. From the article:

ec10-tbl1 Violence isn’t the answer.

We want to be able to stop a running thread or task when we discover that we no longer need or want to finish it. As we saw in the last two columns, in a simple parallel search we can stop other workers once one finds a match, and when speculatively running two alternative algorithms to compute the same result we can stop the longer-running one once the first finds a result. [1,2] Stopping threads or tasks lets us reclaim their resources, including locks, and apply them to other work.

But how do you stop a thread or task you longer need or want? Table 1 summarizes the four main ways, and how they are supported on several major platforms. Let’s consider them in turn. …

I hope you enjoy it.
Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):
July 2007 The Pillars of Concurrency
August 2007 How Much Scalability Do You Have or Need?
September 2007 Use Critical Sections (Preferably Locks) to Eliminate Races
October 2007 Apply Critical Sections Consistently
November 2007 Avoid Calling Unknown Code While Inside a Critical Section
December 2007 Use Lock Hierarchies to Avoid Deadlock
January 2008 Break Amdahl’s Law!
February 2008 Going Superlinear
March 2008 Super Linearity and the Bigger Machine
April 2008 Interrupt Politely

Cringe not: Vectors are guaranteed to be contiguous

Andy Koenig is the expert’s expert, and I rarely disagree with him. And, well, when I do disagree I’m invariably wrong… but there’s a first time for everything, so I’ll take my chances one more time.

I completely agree with the overall sentiment of Andy’s blog entry today:

I spend a fair amount of time reading (and sometimes responding to) questions in the C++ newsgroups. Every once in a while, someone asks a question that makes me cringe.

What makes a question cringe-worthy?

Usually it is a question that implies that the person asking it is trying to do something inappropriate.

Asking how to violate programming-language abstractions is similar: If you have to ask, you probably shouldn’t be doing it.

Amen! Bravo! Absolutely correct. Great stuff. Except that the example in question isn’t violating an abstraction:

For example, I just saw one such question: Are the elements of a std::vector contiguous? Here is why that question made me cringe.

Every C++ container is part of an abstraction that includes several companion iterators. The normal way of accessing a container’s elements is through such an iterator.

I can think of only one reason why one should care whether the elements of a vector are in continuous memory, and that is if you intend to use pointers, rather than iterators, to access those elements. Doing so, of course, violates the abstraction.

There is nothing wrong per se with violating abstractions: As Robert Dewar told me more years ago than I care to remember, some programs are poorly designed on purpose. However, there is something wrong with violating abstractions when you know so little of the data structures used to implement those abstractions that you have to ask strangers on Usenet about your proposed violation. To put it more bluntly: If you have to ask whether vector elements are contiguous, you probably should not be trying to make use of that knowledge.

The reason this analysis isn’t quite fair is that contiguity is in fact part of the vector abstraction. It’s so important, in fact, that when it was discovered that the C++98 standard didn’t completely guarantee contiguity, the C++03 standard was amended to explicitly add the guarantee.

Why is it so important that vectors be contiguous? Because that’s what you need to guarantee that a vector is layout-compatible with a C array, and therefore we have no reason not to use vector as a superior and type-safe alternative to arrays even when we need to exchange data with C code. So vector is our gateway to other languages and most operating systems features, whose lingua franca is the venerable C array.

And it’s not just vector: The TR1 and C++0x std::array, which implements fixed-size arrays, is also guaranteed to be contiguous for the same reasons. (std::array is available in Boost and, ahem, the VC++ TR1 implementation we shipped today.)

So why do people continually ask whether the elements of a std::vector (or std::array) are stored contiguously? The most likely reason is that they want to know if they can cough up pointers to the internals to share the data, either to read or to write, with other code that deals in C arrays. That’s a valid use, and one important enough to guarantee in the standard.

Visual C++ 2008 Feature Pack now available

Back in November, I reported that we’d be shipping Visual C++ 2008 that month (we did!) and that we’d soon thereafter be doing the “agile thing” and shipping a major update mere months later, instead of waiting two years between releases per our prior tradition. I wrote:

The update is expected to be available in beta form in January 2008, and to ship in the first half of 2008. Enjoy!

Well, it’s official: It’s available. Enjoy! Besides major updates to MFC for the latest Office/VS/Vista look-and-feel to support first-class native code development, it also includes most of TR1 (everything except C99 compatibility, and the special math functions that didn’t make it into C++0x):

TR1 (“Technical Report 1”) is a set of proposed additions to the C++0x standard.  Our implementation of TR1 contains a number of important features such as smart pointers, regular expression parsing, containers (tuple, array, unordered set, etc) and sophisticated random number generators.

More information on TR1 can be found at the sites below:

TR1 documentation

Channel 9: Digging into TR1

TR1 slide decks (recommended)

Enjoy, everyone – and thanks, team!


1. This feature pack requires Visual C++ 2008 Standard or above. The only VC08 edition it doesn’t work with is Express; we’ll support Express in a future release.

2. When I wrote that it would be available “in the first half of 2008,” a number of people seemed to automatically interpret that as code for “maybe around June 31.” We’re not always that bad at shipping, fortunately. :-)

3. Yes, I know that June has 30 days.