It's over 200 pages long, and over four years old, but I just heard about it recently. A long, dense discussion of whether certain C++ features (templates, namespaces, RTTI, etc) have a performance cost, and how to write code that incurs as little performance cost as possible. Its official name: ISO/IEC TR 18015:2006(E)  Technical Report on C++ Performance. In addition to runtime performance, it also touches on compile slowness, the "brittle base class" problem, and the different performance characteristics of various STL collections and algorithms. If you care about the speed of your C++ code, you should read this, even if some of it is already familiar to you.

I'd like to give some kind of "Restrained Understatement" award to this sentence:

Template meta-programming  and  expression  templates  are  not  techniques  for novice programmers, but an advanced practitioner can use them to good effect.

To be clear about where these authors are placing the "advanced" bar, I don't use meta-programming, I consider it too advanced for me. And I have 20+ years of C++!

The whole report is platform independent (though embedded systems are discussed separately) and compiler independent, too. I wish it were updated for C++0x, but I guess that will have to wait until C++0x is settled . There's a 14 page bibliography, and you would do well to read many of them, though my source for the link winkily pointed out another possible paper. That one is old enough to get a driver's license, but I think you might enjoy reading it anyway. As the introduction begins:

It is important to understand how your programming language is implemented. Such knowledge dispels the fear and wonder of “What on earth is the compiler doing here?”; imparts confidence to use the new features; and provides insight when debugging and learning other language features. It also gives a feel for the relative costs of different coding choices that is necessary to write the most efficient code day to day.

It's only 23 pages long, and concludes:

... we have considered many of the significant C++ run-time implementation issues. We see that some wonderful language features are almost free, and others can incur significant overhead. These implementation mechanisms are applied quietly for you, behind the curtains, so to speak, and it is often hard to tell what a piece of code costs when looking at it in isolation. The frugal coder is well advised to study the generated native code from time to time and question whether use of this or that particularly cool language feature is worth its overhead.

Good advice, in 1994 or 2010.

Kate