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?

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:

• March 8-13, 2010: Pittsburgh, PA, USA

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

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.

How interesting.

I’m at the ISO C++ meeting in Santa Cruz, CA, USA this week. Ten minutes ago we had a committee straw poll about whether we should remove, deprecate, or leave as-is the export template feature for C++0x. The general sentiment was to remove or deprecate it, with deprecation getting the strongest support because it’s safer per ISO procedure. Deprecation would not remove it from C++0x, but would put the world on notice that the committee is considering removing it from a future standard.

Note: Nothing is happening to export at this meeting. The effect of this straw poll of the committee was to give guidance to the core language working group (CWG) on the committee’s general sentiment on this issue. The CWG is taking this as guidance to produce a detailed proposal to take some action on export at our next meeting in Pittsburgh in March.

I’ll write a longer trip report in the next week, but this was worth noting in real time because it’s the first time export template has been discussed in committee since the highly controversial discussion of my and Tom Plum’s proposal to remove export at the Oxford meeting in 2003.

I recently received the following reader question (slightly edited):

About the (Stroustrup) approach of implementing IsDerivedFrom at page 27 in your book More Exceptional C++: […] why the second pointer assignment in:

static void Constraints(D* p)
{
B* pb=p; // okay, D better inherit from B…
pb=p; // huh? why this again?
}

Isn’t the initialization ” B* pb=p ” enough? What does the second assignment bring to the picture?

Excellent question. Interestingly, here’s the exact text from the book, which contains an additional comment that was intended to answer this specific question (emphasis added):

static void Constraints(D* p)
{
B* pb = p;
pb = p; // suppress warnings about unused variables
}

The reason for the redundant assignment is to try to shut up some compilers that issue warnings about unused variables. In a normal function, this is a helpful warning because, dollars to donuts, it’s a mistake and the programmer meant to use the variable but forgot or accidentally used some other variable instead. In this case, without the second line, pb is declared but never mentioned again, and by adding the extra line that mentions it one more time after its declaration, some compilers stop complaining.

Sometimes, however, we’re intentionally not using the variable, such as in this case where the only purpose of the function is to ensure that code that tries to convert a D* to a B* is compilable. (Note: There are other/better ways to achieve this. See the rest of Item 27 for superior approaches.)

However, in practice even the line “pb = p;” doesn’t shut compilers up very much, because many will still notice that now the second assigned value isn’t used, and will helpfully remind you that you probably didn’t mean to write an apparently useless “dead write” that is never read again. Most compilers offer a compiler-specific #pragma or other nonportable extension to silence this warning, but wouldn’t it be nice to have a portable way to suppress the warning that will work on all compilers?

Here’s a simple one-liner that works on all compilers I tried, and should not incur any overhead: Define an empty function template that takes any object by reference, but doesn’t actually do anything with it and so the empty function body should compile down to nothing. Let’s call it “ignore” – you can put it into your project namespace to avoid collisions on that common name.

  template<class T> void ignore( const T& ) { }

Note that ignore<T>’s parameter does not need a name; in fact, it had better not have a name or else you’ll get the same compiler warning as before about an unused variables, only in a new place.

Using ignore is easy. When you want to suppress the compiler warning, just write:

  static void Constraints(D* p)

  {

    B* pb = p;

    ignore(pb); // portably suppresses the warning

  }

Now all compilers I tried agree that the variable is “used” and stop complaining about pb.

[Oct 20: Updated  to add “const” on ignore<T>’s parameter to also handle rvalues.]

I just received a reader email that asked about GotW #42:

You write "Non-Problem: Zero-Length Arrays Are Okay", but both 14882:2003 and N2914 "[dcl.array]" say "If the constant-expression (5.19) is present, it shall be an integral constant expression and its value shall be greater than zero.". Shall we assume that you overrule the standard? :-) Or am I missing something, like the meaning of "derived-declarator-type-list" (I can’t find it anywhere in 14882:2003)?

I thought the answer might be of interest to other people, so I’m posting it here.

First, this reader gets kudos for consulting not only the ISO C++ standard, but also the current C++0x working draft from June (paper N2914), to do research before asking the question. Good stuff.

He also gets a small penalty point, though, for reading only the subhead text that he quoted from GotW #42, and not the actual short passage the heading introduces. The article already contains the answer to his qustion, and that answer is still the same in the current C++0x draft all these years later:

From 5.3.4 [expr.new], paragraph 7:

When the value of the expression in a direct-new-declarator is zero, the allocation function is called to allocate an array with no elements. The pointer returned by the new-expression is non-null. [Note: If the library allocation function is called, the pointer returned is distinct from the pointer to any other object.]

So the reader is quoting from 8.3.4 [dcl.array], which governs non-heap allocated arrays (e.g., T array[N];). In that case, a zero length is not allowed by the standard. You can’t rely on it in portable code because although it is allowed as an extension in some popular compilers (e.g., Gnu gcc) it is treated as an error in others (e.g., Visual C++).

But the case being discussed in GotW #42 is dynamically allocating an array using the array form of new (e.g., new T[n] where n is zero), which is governed by 5.3.4 [expr.new]. Here, zero length is okay for the reasons given in GotW #42:

The result of "new T[0]" is just a pointer to an array with zero elements, and that pointer behaves just like any other result of "new T[n]" including the fact that you may not attempt to access more than n elements of the array… in this case, you may not attempt to access any elements at all, because there aren’t any.

"Well, if you can’t do anything with zero-length arrays (other than remember their address)," you may wonder, "why should they be allowed?" One important reason is that it makes it easier to write code that does dynamic array allocation. For example, the function f above would be needlessly more complex if it was forced to check the value of its n parameter before performing the "new T[n]" call.

To make GotW #42 completely unambiguous, it could more specifically say that zero-length heap-allocated arrays are okay, which was the case being discussed in the article. But it always helps to read more than the subhead text.

Someone just asked me about getting more proficient in C++, and with their permission I thought I’d share the question and my answer in case it’s of broader interest to folks wanting to improve their C++ skills.

Here’s the question:

I need to take my C++ knowledge up a notch – or two. On a scale of 1-10 I’d consider my C++ knowledge a 5 and would like to get to 7-8 in the next 4, or so, months. As C++ is a large language my quandary is what subject areas, using what study materials, should I focus on to get myself to this next level.

Questions (assuming that I’m going to study approx 2 hrs/day for 4 months):

1. How would you suggest I structure such a course of study (subject areas, 5 of time for each) ?
1.1 If you were in my shoes, how would you proceed?
2. If I was going to study and hopefully know cold one of your books, which do you think I should select?

Here’s my response, which I didn’t limit to my own books. These are the first two “next books” books I would recommend to anyone who already knew the basics of the language and wanted to improve their proficiency with using C++ in production code:

If you’re not already familiar with Scott Meyers’ Effective C++, the current third edition is the plate to start (it’s substantially reworked since the first and second editions).

After that, I’d say the most important is C++ Coding Standards which I wrote with Andrei Alexandrescu. Not only does it cover the top 100 things we felt were important to say about using C++ in production code, and had its guidance peer-reviewed in advance by a who’s-who of the C++ community more than any other C++ book I’ve ever heard of, but it also includes references in each Item for where to find more in-depth treatment. Most Items are just one or two pages, so if you know that Item already you can use it as a refresher; and if you discover ones that you’re less familiar with or rusty on the details, it tells you where to go to find out more.

I’d say those are the two most important that I can suggest. Best wishes with your studies!

A week ago, I attended the summer ISO C++ meeting in Frankfurt, Germany. The C++ committee made a lot of progress on addressing national body comments on the full committee draft published last year, and is well on the way to publishing a second and final CD this winter with a final draft international standard a year after that. To meet that schedule, the committee decided to defer a major feature, “concepts”, and not include it in this standard.

I’m surprised at some of the commentary I’ve been reading on the web about the deferral of concepts, including not just technical inaccuracies but also that their absence in C++0x is somehow a big deal for C++ as a language or is a major geopolitical firestorm. It may feel like a big deal because of the work that’s gone into concepts and the large number of pages of standardese that were needed to specify the feature, and there was a lot of discussion about important design details including heavy traffic on the committee reflectors this spring and early summer that probably made them look more controversial than they are.

But my opinion is that concepts’ presence or absence in C++0x just won’t make much difference to most users. Let me give some reasons why I feel that’s so, and maybe debunk some common misconceptions along the way, in the form of an unofficial FAQ. Note that I was never involved in the design of concepts and don’t speak for the designers, whose views might differ here and there; the following are observations from my point of view as a participant in the standards body (including in Frankfurt last week), and chair of the ISO C++ committee during the entire time concepts were being developed up to the meeting they were voted into the ISO C++0x working draft last fall.

Q: Bjarne Stroustrup is the creator of C++ and a primary designer of concepts. What’s his take?

A: Great question. See Bjarne’s coverage here, published earlier today in Dr. Dobb’s.

Q: Were concepts removed because of political reason X, Y, or Z?

A: No. Concepts were removed because of normal project management considerations. The basic constraint has been phrased in many ways, all of them hitting at the same underlying tension among time, scope, cost, and quality. Here are two examples: “You can pick what goes on the train, or you can pick when the train leaves the station, but you can’t pick both.” “You can have good, fast, and cheap – pick any two.”

Fundamentally, the committee members felt that concepts are desirable but many (though not all) believed that they were still in design mode and needed more “bake time” – a formal poll of committee members in Frankfurt put the expected time at between three and four years – to get up to the quality of a feature that belongs in an international standard. Therefore, the two major options, and the ones that people generally argued for, were to either:

• Prioritize (bigger) scope. Wait for concepts, and accept a delay to the rest of the standard including features that are already finalized and ready to ship.
• Prioritize (faster) schedule. Finish and ship the standard to get already-done features into users’ hands, and decouple concepts to continue work on them for a future standard.

The committee decided to prioritize schedule and ship C++0x sooner while still leaving the door wide open to also adopt concepts later.

Q: Isn’t removing concepts a lot of work? Concepts are used pervasively in the C++0x CD published last fall.

A: Yes, but it’s less work than you’d think. We won’t have a de-conceptized working draft for the post-meeting mailing, two weeks after the meeting, but should have one soon after that. (I would be remiss not to add: Thanks to our always-hardworking project editor, Pete Becker!)

Recall that, until last September, we had a complete draft of C++0x features specified entirely without the use of concepts. And many of the uses of concepts in the draft standard library were just replacements of preexisting non-concepts wording or implicit requirements (e.g., DefaultConstructible, MemberContainer), and will just revert to their previous wording or disappear back into implicitness.

The main C++0x feature that was always specified in terms of concepts was the new range-based for loop (e.g., for( x : collection ) ). I’ve seen some wonder what we’ll do about that, but it’s already done; the non-concepts text for that feature was already voted in at the same Frankfurt meeting.

Q: Wasn’t this C++0x’s one big feature?

A: No. Concepts would be great, but for most users, the presence or absence of concepts will make no difference to their experience with C++0x except for quality of error messages (see below).

C++0x is still a major revision with many new major features, including improvements to templates (e.g., variadic templates, template aliases). C++’s other major new features include lambda functions (which unfortunately for Java were rejected for Java 7), move semantics (aka rvalue references), a concurrency memory model, threading and atomics libraries, initializer lists, and more. Other handy new features include delegating constructors, inherited constructors, defaulted and deleted functions, explicit virtual overriding control, alignment support, static assertions, and more. Not to mention convenience features like range-based for loops and “auto” type inference that are small but will certainly get a lot of use (as they do in C# and Java).

A number of those features are available now or soon in real compilers, including Gnu gcc, Visual C++ 2010, and Intel C++.

Q: Aren’t concepts about adding major new expressive power to the language, and so enable major new kinds of programs or programming styles?

A: Not really. Concepts are almost entirely about getting better error messages.

Yes, concepts would add one truly new expressive capability to the language, namely the ability to overload on concepts. That’s inconvenient to simulate without language support. Concept-based overloading would have been used in a handful of places in the standard library. But that’s it.

By far the most visible benefit of concepts lies in clearer template error messages, including the ability to do separate checking – confirming that a template’s implementation type-checks correctly with all possible valid types without having to instantiate it, and confirming that a given type can be used to instantiate a template without knowing the template’s implementation.

Q: Weren’t concepts all about bringing templates into the 21st century? Where does this leave templates?

A: Templates are still king of the genericity hill, for all their faults in the area of opaque compiler messages.

It’s important to remember that, in 1994, C++ was the only major language whose type genericity capabilities were strong enough to create the Standard Template Library (STL). Today, 15 years later, that is still true; you can’t express the STL’s containers-algorithms design separation well, or at all, using generics facilities in Ada, Java, .NET, or any other significant commercial or research language that I know of; as we learned when doing STL.NET, you can do the containers well with other generics, but not the orthogonalization with algorithms that is the heart of STL design style. Concepts or not, that hasn’t changed.

So my personal view is that templates have been in the 21st century since about 1994. No other language has yet caught up to their expressive power. And C++0x is adding some further power to templates, in particular by adding variadic templates and template aliases, both of which will help to simplify template code.