When I walk into a Chapters or a Borders, seeing the many shelves of books often recalls the ancient writer’s words about quality vs. quantity, circa 1000 BC:
"To the making of many books there is no end."
So true. Yet that observation predates the printing press… and netnews… and now RSS.
(Yes, I’ve been thinking of managing-down my Google Reader subscriptions again…)
I’m pleased to announce that Bjarne and I are going to have another two-day event co-located with SD West in San Jose, California, this March. Most of the talks are new ones we’ve never given publicly before, along with updated classics that people liked the best in the past. This year, three of my four talks have a strong emphasis on concurrency: making your application manycore-scalable, safe locking, and bleeding-fast lock-free coding.
SD graciously let me publish an extra-discount code for readers of this blog. Here it is… if you register before Feb 8, use the following code to get the early bird price (up to $300 off) plus an extra $50 off any package:
Discount code: 8WSUT (expires Feb 8)
Here’s a link to the conference site, and their summary:
Back with brand new and freshly updated content!
The preeminent super session on the C++ language is back at SD West—and full of new and updated material! Join Bjarne Stroustrup, C++ creator and original implementer, and Herb Sutter, C++ and concurrency guru, for two jam-packed days of new and completely updated courses. The seminar is filled with instructive, revealing and highly pragmatic material, and is structured with both talks and panels—not to mention liberal break times, so that the instructors and attendees can mix, eat and chat together.
In addition to lots of information you can use today, Herb and Bjarne will also reveal important, forward-looking information about what’s coming in the next version of the C++ Standard, C++0x, and related efforts. As key designers of several of the new core features, their personal experiences are invaluable.
Finally, for convenience, below is a cut-and-paste of the session topics and abstracts.
I look forward to seeing many of you in San Jose! Best wishes,
Herb
Bjarne Stroustrup
We now know the expected contents of the next C++ Standard, which is targeted to be feature-complete in mid-2008 with final text in 2009. This presentation articulates the main principles of the design of C++0x, outlines the ISO C++ standards process, summarizes the new features and libraries, and gives key examples using new features. Major features, such as concepts, the memory model, and major libraries (such as threads and regular expression matching) are covered by other tutorials, so they will be only briefly mentioned here. The focus of this presentation is the various "minor" features, such as the unified initializer syntax (including variable length initializer lists), decltype and the new form of auto, template aliases, nullptr, generalized constant expressions, "strong" enumerations, the new for statement, static assertions, and rvalue references. But a language is far more than a mere list of features: My aim is to show how these features fit together and fit with C++98 features to better support programming techniques. As ever, the ultimate aim of this language design is to allow clearer expression of real-world ideas, leading to better-performing and easier-to-maintain code. Even the "minor features" can significantly affect your programming style.
Herb Sutter
Our reality show premise is simple: Friends and coworkers nominate code that they consider poorly "fashioned" and ask the show to make over the victim. Our Code Police swoop in with a deal: We’ll provide up to 15 minutes of public assistance in the form of amusing analyses and insightful improvements, discussing tradeoffs and alternatives that can make the code clearer, faster, simpler, and/or safer… but only on the condition that they allow our instructor (that’s Herb) to ruthlessly critique their existing code, and in some cases throw it out altogether, in front of a live studio audience (that’s you). As members of that interactive audience, you will refresh your sense of elegance and beauty, not to mention old-fashioned performance and robustness and maintainability, so often lacking in the broken code littering today’s bleak postmodern corporate landscape.
Bjarne Stroustrup
So: We have classes, derived classes, virtual bases, templates, const, overloading, exceptions, and a host of other useful language features. How do we use them to produce well performing maintainable code? All too often we get seduced into using powerful language features to write clever (i.e., complicated) code rather than to simplify our interfaces and to make the organization of our code easier to understand. This presentation is a tour of the most useful C++ features from the point of view of how they can be used to express the structure of code and to define interfaces that serve basic needs such as flexibility, early error detection, acceptable compile time, performance, decent error reporting, and maintainability.
Herb Sutter
For decades, we enjoyed the "free lunch" of seeing existing applications naturally run faster on new hardware with a faster single CPU core. Computation power is still growing, but in a fundamentally different direction — more and more cores. We can regain the free lunch, but only by building applications in new ways that correctly apply concurrency and parallelism to express lots of latent concurrency that can scale well to a given number of cores but avoids penalizing the application when running on older hardware with one or few cores. This talk addresses the question of how to design new code, and how to migrate existing code, to be multicore/manycore enabled. We will cover best practices for finding and exploiting parallelism in algorithms and data structures, avoiding data structures that harm concurrency, using thread pools and background tasks effectively, and ways to cheat (if not entirely avoid) the specter of Amdahl’s Law. Most code examples will be illustrated using draft standard C++0x syntax, but can be directly translated to popular platforms and concurrency libraries, including Linux, Windows, .NET, and pthreads.
Bjarne Stroustrup and Herb Sutter
This is your opportunity to get "thought leader" answers to your favorite C++ questions! We strongly encourage you to submit your questions in advance, preferably by email or in writing at the beginning of the seminar. Audience questions will also be taken from the floor. Both instructors will answer as many questions as time permits.
(Update of talk voted “Most Informative” at S&S 2007)
Bjarne Stroustrup
An updated version of the talk voted "Most Informative" at S&S 2007: C++ templates are immensely flexible and the basis of most modern C++ high-performance programming techniques and of many el
egant library designs. They are the key language feature behind the standard library’s algorithms and containers: the STL. However, they can also be tricky to use, cause spectacularly bad error messages when misused, and sometimes require unreasonable amounts of code to express apparently simple ideas. C++0x will address these issues directly, and the key to resolving the problems with templates without loss of flexibility or loss of performance is "concepts." Concepts provide a type system for C++ types and for combinations of C++ types and values. Thus, we are able to provide what feels a lot like conventional type checking for template arguments (including simple and elegant overloading based on template arguments). This presentation explains the notion of concepts and shows how to use concepts to write clearer and more robust generic code using templates. People who can’t wait for C++0x before trying out concepts (and other new C++0x features related to generic programming) can try the proof-of-concept implementation, ConceptGCC.
Herb Sutter
From many core to web services, writing highly concurrent software is increasingly becoming a mainstream requirement. But how can we best manage shared state, specifically objects in shared memory? We need to chart a safe course between the Scylla of data corruption due to race conditions on one side, and the Charybdis of excessive contention and even deadlock or livelock on the other side. This talk covers these important problems, as well as the simplicity vs. scalability tradeoff and the composability conundrum. It focuses on solutions, from basics like scoped locks through correct use of lock hierarchies, disciplines to associate data with locks, essential guidelines for writing lock-safe code, and other important best practices. Most code examples will be illustrated using draft standard C++0x syntax, but can be directly translated to popular platforms and concurrency libraries, including Linux, Windows, .NET, and pthreads.
Bjarne Stroustrup
This is a unique opportunity for a "fireside interview" with the creator of C++, moderated by Herb Sutter. After a brief introduction and opening thoughts, Bjarne Stroustrup will take all questions and share thoughtful observations on topics ranging from essential trends affecting software development across languages today, to observations on the strengths and applicability of existing and new languages, to the role of C++ in the 21st century, and more. Attendees are strongly encouraged to submit questions in advance.
Herb Sutter
Concurrent programs increasingly face pressure to avoid locks altogether. This talk focuses on techniques we can sometimes apply to avoid the need for locking and its difficulties. We will cover many effective best practices, from ways to avoid or better manage shared state through to effective use of atomic operations for lock-free coding, including patterns like lock-free mailboxes, low-contention lazy initialization, internally versioned objects, and more. Most code examples will be illustrated using draft standard C++0x syntax and the C++0x memory model, but can be directly translated to popular platforms and concurrency libraries, including Linux, Windows, .NET, and pthreads.
Herb Sutter and Bjarne Stroustrup
This panel is set aside for follow-up comments and discussion on issues that are raised during the seminar. During the other talks and panels, or during between-session chats, questions often come up that the instructors want to research. Some of the resulting information will be of general interest, and this final panel provides the needed convenient opportunity to promulgate it to everyone.
"Tact is the knack of making a point without making an enemy."
A friend recently asked me whether Example 1 below is legal, and if so what it means. It led to a nice discussion I thought I’d post here. Since it was in close to GotW style already, I thought I’d do another honorary one after all these years… no, I have not made a New Year’s Resolution to resume writing regular GotWs. :-)
// Example 1
string f() { return "abc"; }
void g() {
const string& s = f();
cout << s << endl; // can we still use the "temporary" object?
}
This is a C++ feature… the code is valid and does exactly what it appears to do.
Normally, a temporary object lasts only until the end of the full expression in which it appears. However, C++ deliberately specifies that binding a temporary object to a reference to const on the stack lengthens the lifetime of the temporary to the lifetime of the reference itself, and thus avoids what would otherwise be a common dangling-reference error. In the example above, the temporary returned by f() lives until the closing curly brace. (Note this only applies to stack-based references. It doesn’t work for references that are members of objects.)
Does this work in practice? Yes, it works on all compilers I tried (except Digital Mars 8.50, so I sent a bug report to Walter to rattle his cage :-) and he quickly fixed it for the Digital Mars 8.51.0 beta).
// Example 2
string f() { return "abc"; }
void g() {
string& s = f(); // still legal?
cout << s << endl;
}
The "const" is important. The first line is an error and the code won’t compile portably with this reference to non-const, because f() returns a temporary object (i.e., rvalue) and only lvalues can be bound to references to non-const.
Note: Visual C++ does allow Example 2 but emits a "nonstandard extension used" warning by default. A conforming C++ compiler can always allow otherwise-illegal C++ code to compile and give it some meaning — hey, it could choose to allow inline COBOL if some kooky compiler writer was willing to implement that extension, maybe after a few too many Tequilas. For some kinds of extensions the C++ standard requires that the compiler at least emit some diagnostic to say that the code isn’t valid ISO C++, as this compiler does.
I once heard Andrei Alexandrescu give a talk on ScopeGuard (invented by Petru Marginean) where he used this C++ feature and called it "the most important const I ever wrote." And this brings us to the Guru Question, which highlights the additional subtlety that Andrei’s code deftly leveraged…
Corollary: You can take a const Base& to a Derived temporary and it will be destroyed without virtual dispatch on the destructor call.
This is nifty. Consider the following code:
// Example 3
Derived factory(); // construct a Derived object
void g() {
const Base& b = factory(); // calls Derived::Derived here
// … use b …
} // calls Derived::~Derived directly here — not Base::~Base + virtual dispatch!
Does this work in practice on real compilers? Yes: Every compiler I have access to calls the correct Derived destructor, including even ancient Borland 5.5 and Visual C++ 6.0 (and Digital Mars, though DM calls the destructor at the wrong time, as noted above).
Andrei leverages this subtlety (of course) in his ScopeGuard implementation to avoid making the implementation classes’ destructors virtual at all, which is okay in that case because those classes otherwise have no need for one.
Updates:
I knew Hanlon’s Razor: "Never attribute to malice that which can be adequately explained by stupidity." And the variants attributed to Heinlein, described on the same page as adding "… but don’t rule out malice." or "… but keep your eyes open."
But I only just now came across Grey’s Law, which follows the flavor of Clarke’s Third Law: "Any sufficiently advanced incompetence is indistinguishable from malice."
One example that irritates me too is focus-stealing popups. Grr, no, I didn’t mean that enter key to select "Reboot", I was just finishing a paragraph or writing a space. Please, Mr. Callous Software Developer, just leave me alone! I don’t care how important you think your application is — it’s never important enough to pop up on top without warning. No. Bad developer. Down. I said down. Stay.
As a counterexample, I really like how Windows handles the "are you sure you want to run this application?" dialog. Not only does it not steal focus… even better, it ignores the first mouse click when it gets focus. That’s right, if the window is visible but not active, and you click on the "Run" button, it doesn’t also push Run — it merely makes the window active. Then if you hit Run again, it runs. Yes! Good developer!
To paraphrase Hill Street Blues: Let’s be thoughtful out there.
A few weeks ago I blogged about the VC++ update we plan to ship in the first half of next year, which includes extensive additions to MFC as well as TR1. TR1 is the first set of library extensions published by the C++ committee, nearly all of which have also been adopted into the next C++ standard, C++0x. The update will be available to users of Visual Studio 2008 Standard and above in the first half of 2008… but it will not be immediately available to users of our free C++ compiler, Visual C++ Express.
In response to that announcement, an anonymous commenter asked:
Is there planned support later on for TR1 in the Express edition?
Answer: Yes.
The current goal is to include the MFC Update & TR1 bits in the first service pack to Visual Studio 2008, including the Express Edition, but the final decision on this packaging and the timing of SP1 haven’t been firmed up yet. When they are, I’ll mention it here.
Note: Many of you who read this blog aren’t Windows developers. I think you might still be interested in skimming this announcement, because I think it matters to the cross-platform and global C++ community when major vendors are clearly still investing heavily in C++ and C++-based technologies, despite what some naysayers proclaim.
How much does Microsoft care about C++ and non-.NET code? In August, I already blogged about
Now I’m happy to elaborate beyond just hinting, in the wake of announcements made yesterday by our Developer Division VP Soma and by our Visual C++ team. Here’s the scoop.
First the comparatively minor news: We have a ship date. By the end of this month, we will ship Visual Studio 2008 ("Orcas"), including Visual C++ 2008 in particular which includes a number of cool features I’ve blogged about before, such as /MP for parallel builds on multicore machines.
But VC++ isn’t stopping there. Instead of waiting another year or two between releases, we’re immediately doing another one, gratis to VC++ 2008 customers:
In the first half of 2008, VC++ is additionally going to ship an "expansion pack"-like update that will be available to all owners of Visual Studio 2008 Standard and above. This includes two major pieces that I know will be welcome in two major developer communities.
"TR1" is the first set of library extensions published by the C++ committee, nearly all of which have also been adopted into the next C++ standard, C++0x. Now that we know what parts seem to be sealed for inclusion in the next C++ standard and stable, we can start shipping them.
The VC++ 2008 update will include a complete implementation of all parts of TR1 that were voted into C++0x, except only for the section on functions added for compatibility with the C99 standard. The update will include features like:
and a bunch more of all that good stuff lurking inside ISO C++ Library TR1. C++0x may tweak some of the interfaces, and we’ll track that as they do. In the meantime, here they are right in VC++.
I hinted about a "huge update to MFC" back in August. Here’s the scoop…
Using this update to MFC, developers will be able to create applications with the “look and feel” of Microsoft’s own UIs:
All in native C++ code. In MFC.
Oh, and there are also more things… for example, you can also enable your users to customize your application "on the fly" through live drag and drop of menu items and toolbar buttons; use the new Windows shell management classes to enumerate folders, drives and items, browse for folders, and more; and take advantage of many more new controls you can use right out of the box.
Want a quick tour? Get your quick overview with lots of screen shots in our own Pat Brenner’s VCblog entry, and also check out this handy Channel 9 video interview with Pat.
Where did we get the code? This time, we decided to buy rather than build. The code for Office 2007 look-and-feel and other items were based on code we got from BCGSoft rather than code we developed internally.
Some people wondered about this, but it’s just an implementation detail. In particular, here are two questions I’ve seen people ask, and my personal answers (I am not speaking for Microsoft):
Q: Does it matter that this is code originally written by another company (BCGSoft)?
A: No. This update is a Microsoft Visual Studio product, full stop. With the full level of testing and support that implies, today and tomorrow.
Like most software companies, Microsoft routinely both builds its own code and integrates licensed software. We’ve long done the latter for the C++ standard library implementation (from Dinkumware), the Office proofing tools and spelling/grammar/thesaurus/hyphenation/etc. dictionaries, and mapping data for Live, to name just a few off the top.
Q: Does it matter that this isn’t the code the Office team used to implement their own look-and-feel? Why didn’t Microsoft ship Office’s own internal code?
A: No, and because we usually don’t because internal code isn’t at the level required of a product, respectively. I wonder if people realize this is the norm, not the exception, so let me explain a little.
Think of Office as the biggest Windows ISV (independent software vendor) that operates mostly as a separate company, even though it happens to be a sister division. Office has always driven the development of their own UI advances separately from Windows and Visual Studio. Windows and Visual Studio, in turn, have always tried to follow quickly in adding support for Office’s advances so that the Windows shell and other third-party applications could present the same look-and-feel wherever they wanted to, and those implementations have usually been:
The fact that we have an internal and an external "real" implementation for the same thing doesn’t matter. We’ve always done it that way, and the "real" implementation is equal and fully supported. (I think it’s funny that some worry that they’re not getting Office’s original internal ‘real’ implementation; the real "real" implementation is the one that’s not just for internal use, almost by definition!) Once a UI innovation gets into the Windows UI and/or especially the Visual Studio toolset, it’s first-class and here to stay.
Finally, I said this a huge update. What does "huge" mean? This update nearly doubles the size of MFC. Now, "nearly do
ubles the size of X" can be a bad thing. In this case, though, it’s a Good Thing… in my opinion, at least.
The update is expected to be available in beta form in January 2008, and to ship in the first half of 2008. Enjoy!
Finally, let me express some well-deserved appreciation for a HUGE amount of hard work invested by the Visual C++ team, and our libraries team in particular, to make this happen and bring it to customers. Those of us who spend a good fraction of our lives on the second floor of Building 41 saw it firsthand, and know how hard everyone on the team has worked to make this happen at high quality. Thanks for that; it’s been quite a year of PM design work, coding and QA milestones, bug bars, and shiprooms.
For those who’ve asked what Visual C++ is planning beyond this month’s release, the above is an additional part of the answer. Far from the last part, however, because as Ale Contenti said in his announcement on VCblog about our plans beyond VC++ 2008:
"This is just the first step in our drive to improve the native development experience. There’s a lot more that we’re working on, but we hope you enjoy this first milestone."
Stay tuned.
The ISO C++ committee met in Kona on October 1-6. Here’s a quick summary of what we did, and information about upcoming meetings.
As I’ve blogged before (most recently here and here), the ISO C++ committee is working on the first major revision to the C++ standard, informally called C++0x, which will include a number of welcome changes and enhancements to the language itself as well as to the standard library.
The committee is determined to finish technical work on this standard in 2009. To that end, we plan to publish a feature-complete draft in September 2008, and then spend the next year fine-tuning it to address public feedback and editorial changes.
Note that this represents essentially a one-year slip from the schedule I blogged about at the beginning of the year. Why the slip? There are a few major features that haven’t yet been "checked in" to the working paper and that are long poles for this release. Here are three notable ones:
Probably the biggest thing we did at this meeting was to choose time over scope: We decided that we can’t ship C++0x without concepts, but we can and will ship without some or all of the other two.
Concurrency: This was a pivotal meeting for concurrency. We voted a slew of concurrency extensions into the working draft at this meeting, as they happily all got to the ready point at the same time (see below for details):
And we decided to essentially stop there; we still plan to add an asynchronous future<T> type in C++0x, but features like thread pools are being deferred until after this standard.
Garbage collection: For C++0x, we’re not going to add explicit support for garbage collection, and only intend to find ways to remove blocking issues like pointer hiding that make it difficult to add garbage collection in a C++ implementation. In particular, the scope of this feature is expected to be constrained as follows:
Here is a list of the main features we voted into the C++0x working draft at this meeting, with links to the relevant papers to read for more information.
This is an extension from C++/CLI that allows explicitly writing nullptr to designate a null pointer, instead of using the unfortunately-overloaded literal 0 (including its macro spelling of NULL) which makes it hard to distinguish between an null and a zero integer. The proposal was written by myself and Bjarne.
You know how in C++ you can make converting constructors only fire when invoked explicitly?
class C {
public:
C( int );
explicit C( string );
};void f( C );
f( 1 ); // ok, implicit conversion from int to C
f( "xyzzy" ); // error, no implicit from string literal to C
f( C("xyzzy") ); // ok, explicit conversion to C
But C++ has two ways to write an implicit conversion — using a one-argument constructor as above to convert "from" some other type, or as a conversion operator "to" some other type as shown below, and we now allow explicit also on this second form:
class C {
public:
operator int();
explicit operator string(); // <– the new feature
};void f( int );
void g( string );C c;
f( c ); // ok, implicit conversion from C to int
g( c ); // error, no implicit from C to string
g( string(c) ); // ok, explicit conversion to C
Now the feature is symmetric, which is cool. See paper N2434 for how this feature is being used within the C++ standard library itself.
As I wrote in "The Free Lunch Is Over", chip designers and compiler writers "are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster." This only gets worse in the presence of multiple cores and processors.
A memory model is probably of the lowest-level treaty between programmers and would-be optimizers, and fundamental for any higher-level concurrency work. Quoting from my memory model paper: "A memory model describes (a) how memory reads and writes may be executed by a processor relative to their program order, and (b) how writes by one processor may become visible to other processors. Both aspects affect the valid optimizations that can be performed by compilers, physical processors, and caches, and therefore a key role of the memory model is to define the tradeoff between programmability (stronger guarantees for programmers) and performance (greater flexibility for reordering program memory operations)."
Closely related to the memory model is the feature of atomic types that are safe to use concurrently without locks. In C++0x, they will be spelled "atomic<T>". Here’s a sample of how to use them for correct (yes, correct!) Double-Checked Locking in the implementation of a singleton Widget:
atomic<Widget*> Widget::pInstance = 0;
Widget* Widget::Instance() {
if( pInstance == 0 ) { // 1: first check
lock<mutex> hold( mutW ); // 2: acquire lock (crit sec enter)
if( pInstance == 0 ) { // 3: second check
pInstance = new Widget(); // 4: create and assign
}
} // 5: release lock
return pInstance; // 6: return pointer
}
You might have noticed that the above example used a lock<mutex>. Those are now in the draft standard too. C++0x now includes support for threads, various flavors of mutexes and locks, and condition variables, along with s
ome other useful concurrency helpers like an efficient and portable std::call_once.
Here are the next meetings of the ISO C++ standards committee, with links to meeting information where available.
The meetings are public, and if you’re in the area please feel free to drop by.
"I find that the harder I work, the more luck I seem to have."
– Thomas Jefferson (1743 – 1826)
Over the past 15 years or so that I’ve been giving software development talks, I’ve never had the chutzpah to suggest one of my own talks be considered "required viewing" for serious developers regardless of language or platform. But I’m going to suggest it now.
Two years ago, several highly experienced software architects I know (whose names many of you gentle readers would recognize) complained to me privately that "we shouldn’t let developers labor in ignorance" of how the enormous complexity of modern commodity computers affects our code’s performance and correctness. From that seed and others like it sprang this talk, now freely available online:
Machine Architecture: Things Your Programming Language Never Told You (117 minutes)
Video: Google video (recorded live on Sep 19, 2007)
Slides: PDF slides
Abstract: Programmers are routinely surprised at what simple code actually does and how expensive it can be, because so many of us are unaware of the increasing complexity of the machine on which the program actually runs. This talk examines the “real meanings” and “true costs” of the code we write and run especially on commodity and server systems, by delving into the performance effects of bandwidth vs. latency limitations, the ever-deepening memory hierarchy, the changing costs arising from the hardware concurrency explosion, memory model effects all the way from the compiler to the CPU to the chipset to the cache, and more — and what you can do about them.
Teaser: Would you be surprised to discover that only about 1% (one percent) of all the transistors on your modern CPU exist to ever compute anything? And that the other 99% (ninety-nine percent) of your CPU’s transistors are essentially dedicated to nothing but hiding memory latency? Those are round numbers, of course. But you get the idea…
This is a talk I wish I’d been able to attend years ago. Consider making this required viewing for your team, including for new hires in software development roles. I guarantee it’ll be time well invested.
Here’s one suggestion: Roll your own training session. Arrange an extended lunch brownbag for your developers in a conference or training room, give each person a printout of the PDF slides to follow along and make notes, and display the video on the big screen. For extra benefit, leave a little time for group discussion, both during the session (the Pause feature is your friend) and afterwards ("how does this apply to our projects?"). Presto, instant training session — and you don’t even have to put your developers on a plane to attend a class somewhere, or arrange for a speaker to fly out to your site.
Finally, if you like the material and agree that it’s worthwhile, please help spread the word. For example, you can tell Slashdot by going to Submit Story. Or, if you prefer, you can tell Digg, or Reddit, or one of the others… you know the rest of the usual suspects.
Enjoy!
Sutter’s Mill 