Category: C++

Comment policy

[Updated 3/17 for clarity.]

On this blog, I’ve always been happy to follow a policy of not editing or filtering comments, and to let comments stand whether the commenter agrees with me or not. However, recently a few comments have strayed into name-calling (e.g., I’d never heard the term “freetard” until last week), and I’ve decided to start moderating all comments, and to remove some existing comments that seem to me to be disrespectful of others.

Fortunately, the vast majority of comments aren’t like that, and opinions that respectfully disagree with my own or with those of other commenters continue to be welcome. Thanks for understanding.

Trip Report: March 2010 ISO C++ Standards Meeting

[Note: I usually post trip reports after the public post-meeting mailing goes live a few weeks after the meeting, so that I can provide links to minutes and papers. This time, I wanted to post the report right away to share the news. If you’re interested in the post-meeting papers, including the official minutes, watch the 2010 papers page which is where they will appear in a few weeks.]

 

The ISO C++ committee met in Pittsburgh, PA, USA on March 8-13, 2010, hosted by the CERT Software Engineering Institute at Carnegie Mellon University. As usual, about 50 experts attended, and we had eight official national body delegations from Canada, Finland, France, Netherlands, Spain, Switzerland, United Kingdom, and United States.

IMG_0396The meeting just concluded a few minutes ago (yes, the meetings run through Saturday afternoon). Here are some highlights of what happened today, which was another landmark in the progression of the C++0x standard.

Approved Final Committee Draft (FCD) for C++0x

The biggest news is that this afternoon we voted in the final remaining feature changes to C++0x, and to much applause then unanimously approved the text for international ballot as a Final Committee Draft (FCD). FCD means that, assuming no surprises, we intend to do only bug fixes and editorial corrections for the next year or so, and then ballot a final standard. If we can do that, assuming all goes well, C++0x could officially be published as soon as next year as ISO C++ 2011, and we can stop with the “x-is-hex” jokes and just start calling it C++11.

This is a big milestone, and it was achieved thanks to removing a couple of controversial features last summer and a whole lot of work by the ISO C++ committee members over the past six months in particular. That work includes countless hours spent between our full face-to-face meetings at face-to-face ad-hoc meetings to swat library bugs, teleconferences on resolving core language questions, and triple-digit person-hours invested in four teleconferences during December-February purely about C and C++ compatibility that have greatly helped to identify and attempt to resolve minor areas of divergence between the C++0x draft standard and the C1x draft standard (as both are now in progress; C1x is targeting completion and publication in 2012).

All in all, your committee members have put in an enormous amount of effort to bring this in, and the draft is in far better shape for this meeting than anyone could have expected last summer. For comparison, in my and several others’ opinions, it’s in better shape than the FCD of the C++98 standard.

Since we’re closing down this round of standardization, we didn’t make many exciting technical changes. Here are two technical highlights of the meeting that are likely of general interest, finally adopting changes we’ve contemplated before.

Removed Export Template

As I reported after the last meeting (here and here), the committee considered the question of whether to deprecate, remove, or leave in the “export template” feature.

For context, the only reason we’re even considering this is because Edison Design Group (EDG), the only company to ever implement export, is recommending export be removed or deprecated. Recall that back in the 1990s the committee originally voted the feature in over EDG’s objections in the first place, then in the late 1990s and early 2000s EDG graciously and gallantly went on to invest enormous effort to implement the feature in order to conform to the standard, and so the committee was loath to punish them again by now removing the feature on them. However, given the passage of time, EDG reports that their experience in the field has been that nearly no one actually uses the feature, and that it would be right (and okay with EDG) to deprecate or remove it.

At our previous meeting, the general sentiment was in favor of deprecation only. However, at this meeting EDG reported that they would prefer the feature to be removed rather than just deprecated, because a deprecated feature is still part of the standard and required for conformance. By removing it from C++0x, it removes the maintenance burden of being forced to support export indefinitely to maintain full standards conformance (though of course EDG will continue to support it as an extension in their compiler front end for however long seems right based on their own customers’ demand).

The committee agreed, and today voted to remove export entirely from C++0x. The “export” keyword is still reserved for future use, but has no defined meaning in the C++0x standard.

Deprecated Exception Specifications, Added noexcept

As also considered at our previous meeting, this week we went ahead and deprecated throw-specifications (e.g., throw(), throw( Base, Derived1 )). For rationale, see the two background references referred to in the proposal, one of which is an article by me:

As noted in the second reference, “A non-inline function is the one place a ‘throws nothing’ [i.e., throw()] exception-specification may have some benefit with some compilers.” Because this would have some utility, there is a replacement for empty exception-specifications… the noexcept keyword, which has the basic use syntax “void f() noexcept {…}”. It optionally takes a compile-time constant true/false expression that if true means the noexcept is in force, which helps libraries to write efficient overloads. This feature will be written about for years to come, but that’s the basic idea.

Here’s the concise summary from the core working group report by Steve Adamczyk (of EDG fame and longtime core working group chair):

We discussed two things related to exception specifications: noexcept (N3050), and deprecating exception specifications (N3051). There was some spirited discussion of what happens when you violate a promise not to throw. In the end, we decided that in such a circumstance terminate() gets called, and it’s unspecified whether any cleanup is done for local variables between the throw point and the point of the violated noexcept. It’s believed that for efficient implementations of exception handling a noexcept will not add any overhead and will not restrict optimization opportunities.

The old-style exception specifications, including the throw() form, will now be deprecated. The library specification needs to be updated to use noexcept instead, and that won’t happen at this meeting.

Note that the decision to call terminate() is not final and alternatives will be considered at future meetings. There was general (but not universal) agreement that the program should not be allowed to continue executing if a noexcept is violated because in that case the program will almost certainly be in a corrupt state, and so the consensus was in favor of guaranteeing to call terminate() instead of allowing arbitrary undefined behavior, but it’s possible that a comfortable middle ground between those two options may yet be found.

Looking Forward

We wrapped up with a presentation of the scheduled dates and locations for the next few ISO C++ standards committee meetings (meeting information link included where available):

Finally, here’s a copy of summary slide I presented, which will also be in the post-meeting mailing. Here’s to C++11 (we hope)!

 

Pittsburgh slide.jpg

Where can you get the ISO C++ standard, and what does “open standard” mean?

In my role as convener of the ISO C++ committee, I get to field a number of questions about the committee and its process. It occurred to me that some of them might be of more general interest, so I’ll occasionally publish an edited version of my reply here in case other people have similar questions. Note that the quoted questions may be paraphrased.

Today’s question comes from someone who recently asked about why, if ISO C++ is an open standard, ISO charges for it and we can’t just download it for free.

The short answer is that people sometimes confuse “open” with “free.” ISO standards aren’t “open” like the O in FOSS, they’re “open” like “not developed behind closed doors.” Anyone who wants to pay for membership in their national body (if their country participates in ISO and in the specific project in question) is able to come join the fun. In free-as-in-beer terms, this means that experts are welcome to come to the ISO brewery at their own expense and volunteer their time to help brew the beer, and then when the beer is ready the customers still pay ISO to drink it (the helpers don’t get a cut of that, only a free bottle for their personal use and the satisfaction of having brewed a mighty fine keg).

Longer answer follows:

ISO C++ claims to be an OPEN STANDARD. Where can I download the OPEN STANDARD for ISO C++.

All published ISO standards are available for sale from the ISO store, via http://iso.org. You can purchase a copy of the latest currently published C++ standard, 14882:2003, here for CHF 380:

Also, your national standards body may sell a copy. For example, the ANSI store sells a PDF version here for US$ 30:

However, before you buy one of those, note that we’ve been actively working on a new revision to that standard, and hope to be done in the next year or so. You can get a free copy of the latest (but incomplete) draft of the C++ standard here:

Note that this is a working draft as of a couple of weeks ago; it is not the standard currently in force, and it is not exactly the standard that will be published in the next year or two, but it is a draft of the latter that’s in pretty good shape but will still get some editorial corrections and technical tweaks.

By the way, what does it mean, that the STANDARD of a widely used language is OPEN? Especially if I have to pay for it?

All ISO standards are "open standards" in that they’re developed in an open, inclusive process. All member nations of ISO are eligible to participate, send experts, contribute material, vote on ballots, and so forth. Additionally, some working groups, including C and C++, make all of their papers and all working drafts freely available on the web, as with the link above; the only thing a working group is not allowed to make freely available, except with special permission from ISO, is the text of the final standard it produces, because ISO reserves the right to charge for that.

Could you explain to me, what should it mean if the STANDARD of a widely used language was CLOSED?

Generally, that means it was developed privately by some closed industry group or consortium that not everyone is allowed to join and participate in. Some standards are developed behind closed doors controlled by some company or companies. ISO standards are not like that.

Best wishes,

Herb

Effective Concurrency: Prefer Futures to Baked-In “Async APIs”

This month’s Effective Concurrency column, Prefer Futures to Baked-In “Async APIs”, is now live on DDJ’s website.

From the article:

When designing concurrent APIs, separate "what" from "how"

Let’s say you have an existing synchronous API function [called DoSomething]… Because DoSomething could take a long time to execute (whether it keeps a CPU core busy or not), and might be independent of other work the caller is doing, naturally the caller might want to execute DoSomething asynchronously. …

The question is, how should we enable that? There is a simple and correct answer, but because many interfaces have opted for a more complex answer let’s consider that one first.

I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns:

The Pillars of Concurrency (Aug 2007)

How Much Scalability Do You Have or Need? (Sep 2007)

Use Critical Sections (Preferably Locks) to Eliminate Races (Oct 2007)

Apply Critical Sections Consistently (Nov 2007)

Avoid Calling Unknown Code While Inside a Critical Section (Dec 2007)

Use Lock Hierarchies to Avoid Deadlock (Jan 2008)

Break Amdahl’s Law! (Feb 2008)

Going Superlinear (Mar 2008)

Super Linearity and the Bigger Machine (Apr 2008)

Interrupt Politely (May 2008)

Maximize Locality, Minimize Contention (Jun 2008)

Choose Concurrency-Friendly Data Structures (Jul 2008)

The Many Faces of Deadlock (Aug 2008)

Lock-Free Code: A False Sense of Security (Sep 2008)

Writing Lock-Free Code: A Corrected Queue (Oct 2008)

Writing a Generalized Concurrent Queue (Nov 2008)

Understanding Parallel Performance (Dec 2008)

Measuring Parallel Performance: Optimizing a Concurrent Queue (Jan 2009)

volatile vs. volatile (Feb 2009)

Sharing Is the Root of All Contention (Mar 2009)

Use Threads Correctly = Isolation + Asynchronous Messages (Apr 2009)

Use Thread Pools Correctly: Keep Tasks Short and Nonblocking (Apr 2009)

Eliminate False Sharing (May 2009)

Break Up and Interleave Work to Keep Threads Responsive (Jun 2009)

The Power of “In Progress” (Jul 2009)

Design for Manycore Systems (Aug 2009)

Avoid Exposing Concurrency – Hide It Inside Synchronous Methods (Oct 2009)

Prefer structured lifetimes – local, nested, bounded, deterministic (Nov 2009)

Prefer Futures to Baked-In “Async APIs” (Jan 2010)

C++ and Beyond: Summer 2010, Vote the Date

I always enjoy teaching together with Scott Meyers and Andrei Alexandrescu, not only because it means I get to work with good friends, but also because I get to listen to them speak. Scott and Andrei always have interesting and useful things to say and say them well. We occasionally speak at the same big conferences, but at those we’re often scheduled at the same time and so we don’t get to hear each other’s sessions (and attendees likewise have to choose one competing session or the other for that time slot), and presenting in large rooms to hundreds of people makes it hard to get much quality face time with the individual audience members.

So I’m really looking forward to spending three days together with Scott and Andrei and a limited number of attendees at a new event called C++ and Beyond:

What do C++ programmers think about these days? Perhaps the new features from C++0x that are becoming commonly available and that introduce fundamental changes in how C++ software is designed. Perhaps the increasing importance of developing effective concurrent systems. Perhaps the continuing pressure to create high-performance software. Possibly the impact of new systems programming languages such as D. Most likely, all of the above, and more.

C++ legends Scott Meyers, Herb Sutter, and Andrei Alexandrescu think about these things, too — all the time. Scott and Herb are neck-deep in C++0x, while Andrei is literally writing the book on D (The D Programming Language). Herb and Andrei put the pedal to the metal on applied concurrency and parallelism; Herb is writing the book on that topic (Effective Concurrency). All three focus on the development of high-performance systems, a topic Scott’s writing a book about (Fastware!).

This summer, Scott, Herb, and Andrei will host an intensive three-day technical event focusing on “C++ and Beyond” — an examination of issues related to C++ and its application in high-performance (typically highly concurrent) systems, as well as related technologies of likely interest to C++ programmers.

We know it’ll be in the Seattle area. We know it’ll be this summer. What we don’t know is which of the two candidate dates (in June or August) works best for you, so we thought we’d let you decide: If you’re potentially interested in attending, please vote for your preferred date. At that page you can also let us know what kinds of topics you’d like to see covered.

Once we finalize the details we’ll post them and open registration. You can subscribe to follow announcements via this feed.

We hope to see you in the beautiful Pacific Northwest this summer.

Stroustrup on Teaching Software Developers

Recommended reading (it’s short), from the January 2010 issue of CACM:

What Should We Teach New Software Developers? Why?
by Bjarne Stroustrup

It’s a wonderfully accurate and concise summary of the disconnect between the ivory tower and the trenches – i.e., (some) computer science academics and (some) software development industry managers, with commentary on other topics like why or why not to regulate the software development industry.

My favorite part is this from the conclusion (emphasis added):

We must do better. Until we do, our infrastructure will continue to creak, bloat, and soak up resources. Eventually, some part will break in some unpredictable and disastrous way (think of Internet routing, online banking, electronic voting, and control of the electric power grid). …

Bjarne isn’t prone to disaster warnings (indeed, this is the first time I recall seeing a comment like this from him, even over a beer or three), but he’s right. This hits directly on an issue I’ve also been giving thought to in recent years: As an industry and a society, we routinely underestimate the degree to which we’ve gradually allowed our automated civilization to become reliant on computers and software, and vulnerable as a result. We’ve been satisfied with making any given system “reliable enough” for the intended application (e.g., having a much higher bar for life-critical software than for a word processor), and so far we’ve been able to get away with that without the level of broad regulation for software development that is routinely required for other disciplines like engineering that are involved in providing essential products and services. Of course, as Bjarne points out, one reason for the lack of regulation of the software development industry is that we don’t know (and/or can’t agree on) exactly what to require and how to measure it; we’re just not as mature a field yet as civil or mechanical engineering.

Recognizing the potential scope of a catastrophic and systemic software failure in the field – one that disables a vital piece of infrastructure (say, electric power or food distribution, country-wide for a month) and that can’t be patched with a remote update – adds impetus to understanding and solving the kinds of issues Bjarne writes about.

Guest Blog: Words Matter

This morning my colleague Rob Hanz wrote an interesting email that went viral in my corner of Microsoft. He graciously allowed me to share it with you here. I hope you enjoy it too.

Blink and subconscious messaging
Robert Hanz

I was reading Blink last night, and one of the things it mentioned is how subconscious signals can significantly impact conscious activity. For instance, one experiment took jumbled, semi-random words and had the subjects arrange them into sentences. After they finished these, they would need to go down to the hall and speak to a person at an office to sign out of the test.

But the test wasn’t the actual sentences – mixed in with the words to form sentences were one of two sets of words. One set had a lot of words regarding patience and cooperation, while the other had words regarding belligerence and impatience. The test was to see the behavior of the student when the person they needed to talk to was engaged in a conversation and was unable to help them.

The group that had the belligerent words waited, on average, about 5 minutes before interrupting the conversation. The group with the patient wordset waited indefinitely. The test was designed to end after I believe 10 minutes of waiting – not a single “patient” subject ever interrupted the conversation.

Reading this, one of the things that came to mind was some of the different messaging used by waterfall projects vs. agile projects, and how often we hear them.

Waterfall:
“Bug” (used for just about anything that needs to be done by a developer)
“Priority one”
“Due by”
“Stabilization”
(this in addition to the frequently long list of “bugs” that confronts developers every day)

Agile:
“User story”
“Customer value”
“Velocity”
(in addition, the list of work to be done is usually scoped to be possible within a single week)

When I thought about the differences in words, I was really struck by how different the messaging was. In the waterfall case, the message was overwhelmingly negative – it focused on failures, urgency, and almost a sense of distrust. It seemed that the language seemed to be geared around ways that individuals messed up, and how everything is an emergency that must be dealt with immediately. And, if you think about it, in a waterfall culture there is typically no frequent reward or messaging of success – the best you can typically hope for (for much of the cycle) is to avoid failure. And the idea that you’re actually producing value is very much removed from the language.

On the other hand, the agile language itself focuses on results, not failures. Stories are typically “done” or “not done,” and while bugs are certainly tracked, at a high level that’s usually just a statement that the story is “not done.” Combine this with sprint reviews (where the team shows what they’ve accomplished), and the overall message becomes very much focused on the successes of the team, rather than the failures. Progress is measured by value added, not by failures avoided. Even something as low-level as TDD consistently gives its practitioners a frequent message of success with the “green bar.”

While I certainly believe that agile development has many advantages in terms of reducing iteration time and tightening feedback loops, among other things, is it possible that something as simple as the shift in language is also a significant part of the effectiveness? That by priming individuals with messages of success and value, rather than messages of failure, that morale and productivity can be boosted?

Trip Report: October 2009 ISO C++ Standards Meeting

The ISO C++ committee met in Santa Cruz, CA, USA on October 19-24. You can find the minutes here, which include the votes at the whole-group sessions but not the details of the breakout technical sessions where we spend most of the week.

The good news is that there’s little new technical news. We did a lot of work during the week, but it was mostly working on refining the standard, deciding integration questions of how two language features should work together in cases not clearly described, fixing bugs, and answering national body comments on our first public draft last fall (those are now nearly all answered). We expect to produce another public draft at our next meeting in March.

We did vote in one small feature that I and Lawrence Crowl in particular had been working on: a simple async() facility to launch asynchronous work easily without messing with packaged_tasks and raw threads. Here’s a sample use, also demonstrating a simple use of the futures library and a lambda function for kicks:

  future f = std::async( []{ OtherWork(); } );

  //... do our own work concurrently with OtherWork ...

  OkayNowWeNeedTheResult( f.get() );  // blocks if necessary until f is ready

If you’ve been following the futures library, you’ll notice a name change above: We also renamed unique_future<T> to just plain future<T> as part of recasting the futures wording to make it clearer and more consistent. That’s an example of the kind of cleanup work being done.

Near the end of the meeting, we also discussed deprecating export (as I reported earlier) and exception specifications other than throw()-nothing. There seemed to be significant support for deprecating both, and so we’ll probably see a concrete proposal at our next meeting.

In sad news, the convener (chair) of the committee for the past year, P.J. Plauger, stepped down at the end of the meeting. After I had been the convener for two three-year terms from 2002 to 2008, I decided it was time for someone else to have a go and so Plauger replaced me a year ago. He has done a really great job over the past year and his contributions in that role will be missed, but we won’t lose his services entirely as he remains an active participant in the committee. I will probably volunteer again to replace him.

That’s pretty much it. The next meeting of the ISO C++ standards committee is in March:

(Edited to fix “2009” in the title and add a link to the Pittsburgh meeting invitation.)

Hoare on Testing

On the flight to the ISO C standards meeting this morning, I was reading this month’s issue of CACM, and found that Sir C.A.R. (Tony) Hoare wrote a nice piece called Retrospective: An Axiomatic Basis for Computer Programming.

Hoare has long been a noted proponent of axioms and formal proofs of program correctness. In that light, the following passage on testing and axioms struck me as well put and I thought I’d share it (emphasis added):

One thing I got spectacularly wrong. I could see that programs were getting larger, and I thought that testing would be an increasingly ineffective way of removing errors from them. I did not realize that the success of tests is that they test the programmer, not the program. Rigorous testing regimes rapidly persuade error-prone programmers (like me) to remove themselves from the profession. Failure in test immediately punishes any lapse in programming concentration, and (just as important) the failure count enables implementers to resist management pressure for premature delivery of unreliable code [or forces management to be explicitly unreasonable in the face of bug bar data and specific failure cases having an objective severity –hps]. The experience, judgment, and intuition of programmers who have survived the rigors of testing are what make programs of the present day useful, efficient, and (nearly) correct. Formal methods for achieving correctness must support the intuitive judgment of programmers, not replace it.

My basic mistake was to set up proof in opposition to testing, where in fact both of them are valuable and mutually supportive ways of accumulating evidence of the correctness and serviceability of programs. …

He also mentions many other useful observations and reminds, including the value of assertions to find, not run-time errors, but programming bugs. (See also C++ Coding Standards Item 68: Assert liberally to document internal assumptions and invariants.)

The whole article is good reading, and not long. Recommended.