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.

This afternoon I was just finishing up my next Effective Concurrency article (it’ll be up in a few days), when some spam email arrived. Just as my fingers’ auto-delete macro was about to fire, I noticed something odd about the name of the attachment and did a double-take:

Cool! There must be some kind of new truth-in-advertising laws for spammers.

Yes, I know that as programmers we could argue about naming all day long. We could point out that maybe “virusLoader.gif” or “exploit_exploit_muhaha.gif” would be a little better, and argue about the relative merits of camel case and underscores. But there’s no need; I think “runnable.gif” is short, clear, and definitely good enough. (Evidently someone else thought so too, and just shipped it.)

An amusing hearse, seen on a neighborhood street:

Here’s a close-up of the license plate:

 

 

Made my morning.