The ISO C++ committee met in San Francisco, CA, on September 15-20. You can find the minutes here, including the votes to approve papers.
The most important thing the committee accomplished was this:
Complete C++0x draft published for international ballot
The biggest goal entering this meeting was to make C++0x feature-complete and stay on track to publish a complete public draft of C++0x for international review and comment — in ISO-speak, an official Committee Draft or CD. As I predicted in the summer, the committee achieved that at this meeting. Now the world will know the shape of C++0x in good detail. Here’s where to find it: The September C++0x working draft document is essentially the same as the September 2008 CD.
This is “it”, feature-complete C++0x, including the major feature of “concepts” which had its own extensive set of papers for language and library extensions — I’ll stop there, but there are still more concepts papers at the mailing page and some more still to come during the CD phase. (If you get the impression that concepts is a big feature, well, it is indeed easily the biggest addition we made in C++0x.)
What’s next? As I’ve mentioned before, we’re planning to have two rounds of international comment review. The first of two opportunities for national bodies to give their comments is now underway; the second round will probably be this time next year. The only changes expected to be made between that CD and the final International Standard are bug fixes and clarifications. It’s helpful to think of a CD as a feature-complete beta, and we’re on track to ship one more beta before the full release.
And a new convener
On a personal note, I’m very happy to see this accomplished at the last meeting during my convenership. I’ve now served as secretary and then convener (chair) of the ISO C++ committee for over 10 years, and my second three-year term as convener ended one week after the San Francisco meeting. A decade is enough; I decided not to volunteer for another term as chair.
As of a few weeks ago, P. J. Plauger is the new convener of ISO/IEC JTC1/SC22/WG21 (C++). Many of you will know P.J. (or Bill, as he’s known within the committee) from his long service to the C and C++ communities, including that he has been a past convener of the ISO C standards committee, past editor of the C/C++ Users Journal, the principal author of the Dinkumware implementation of the C++ standard library, and recipient of the 2004 Dr Dobb’s Journal Excellence in Programming Award, among various other qualifications and honors. He has been a regular participant at ISO C++ meetings for about as long as they’ve been held, and his long experience with both the technology and the ISO standards world will serve WG21 well.
I’m very happy to have been able to chair the committee during the development of C++0x. Now as we move from “develop mode” into “ship mode” it will be great to have his experienced hand guiding the committee through the final ISO process. Thanks for volunteering, Bill!
Sutter’s Mill 
The training of both advocates and solicitors in Scotland takes the same route at the initial stages. ,
Thanks for all you’ve done for the community over the years. I don’t have anything approaching the available time necessary to do as much as you have.
I’m excited about the performance and legibility benefits of C++0x. Sadly, it will be several years before I’ll be allowed to use them.
C++ has always given me tons of problems, but I’m slowly learning how to work it.
Hello Herb,
Could you please suggest me where can I find a list of ever proposals. I just can’t find it at the C++ standards committee’s site :-(
I have a proposal of forward declaration of nested types:
class X;
class X::Y;
enum X::Z;
struct X::W;
I just don’t know if a such proposal has been ever proposed :-)
P.S.
Beg my pardon for my poor English.
> How could you possibly manage to screw up not fixing the EXTREMELY OBVIOUS limitations in templates?
Well, why didn’t you propose it to the C++ standards committee? I don’t see a paper detailing this proposal anywhere. They’ve been taking suggestions from the public for 10 years now; it if were an “EXTREMELY OBVIOUS” limitation, I’m guessing that someone would have made a proposal to change it. Nobody did.
Which suggests that it’s only “EXTREMELY OBVIOUS” to you.
Herb,
You failure. I have no more faith in you; you’re senile, and you don’t get it.
After 10 years, you can’t manage to fix up templates and allow string literals as nontype template parameters? You can’t manage to allow floating point nontype template parameters? How could you possibly manage to screw up not fixing the EXTREMELY OBVIOUS limitations in templates? It’s too ridiculous for words, you simply fail.
Nor can you manage to be innovative enough for: http://www.digitalmars.com/d/2.0/traits.html
I hope somebody younger and who understands the limitations will lead the next C++ standard after this one.
– Thanks for letting me down
Mister Plaugher is a fine succeding convener, and should do an excellent job; even so, the impact of your perspective is obvious, and you, sir, will be missed.
Thank you for ten years with only one significant mistake, a record that is unmatched in any other large industrial language. You’ve done us all – not just programmers, but everyone using those tools built thereby – a service that only a few will ever understand.
(Export, in case you’re curious.)
Thanks for all the hard work — it’s a great achievement. I’ll bet you’re looking forward to starting on C++1x!
Congratulations to the committee and personally to you on behalf of the C++ community.
Over the last thirteen years, I’ve personally made a living mostly by developing on C++ and I appreciate the quality and quantity of effort that you and other members of the committee put into this wonderful piece of engineering that is the C++ Programming Language and its _orderly_ expansion
Thanks to you, Dr. Stroustrup and all the committee members, our company can provide CTI applications for the 9-1-1 emergency market that save lives on a daily basis.
I appreciate your personal sacrifice and understand that you must move on to greater and better things–while still being part of the C++ community, of course.
I had an opportunity to attend the Microsoft PDC and I’m looking forward to work with the released version of VC++.
Regards,
–Javier
David asked: “When do you think we will be able to actually write and compile code using this new standard?”
Both Visual C++ and gcc have a few features already, and are adding more in their next releases. I do know that our next release of VC++ (for which the community preview shipped last week) includes rvalue/move semantics, lambdas, and several other useful features. I know of two other compilers (gcc and one other) that are planning to add support for lambdas in their next release.
Nathan said: “I still see so much newly-written code employing hand-coded loops [instead of STL algorithms], …”
One of the many advantages of lambdas is that they make STL algorithms far more usable. I gave a few examples here.
@Anonymous Cowherd: “Um, that’s because almost all the C++isms you mention are *bad ideas*. [etc]”
I’ve made a career out of improving code written by people who adhere to the claims you made.
In fact, my code is usually smaller *and* faster. Certainly it’s easier for people to understand than the “C+” [vs C++] that I’ve had to upgrade.
In order to effectively *use* the STL, the programmer must understand those “subtle” differences between the Containers and Algorithms. Perhaps from there the programmer will gain enough insight to learn how to deal with type aglebras properly.
Then, and only then, will I not have effectively infinite work to do.
@Nathan: “I still see so much newly-written code employing hand-coded loops [instead of STL algorithms], raw pointers and manual memory management [instead of smart pointers], overuse of the inheritance mechanism, copying-and-pasting code [instead of writing generic code using templates], choosing the wrong STL containers, using C-style casts [instead of C++ casts], etc. etc.”
Um, that’s because almost all the C++isms you mention are *bad ideas*. STL’s weird “foreach” is always less efficient and harder to debug than a C-style for loop (and begin()/end() iterators are equally bad but wordier). Auto_ptr is a step down in maintainability from new/delete, which is a step down in flexibility from malloc/realloc/free. STL containers were a neat idea in theory, but in practice it’s impossible to switch out a std::vector in favor of a std::list, or std::map for std::hash_map (oh, wait, does hash_map officially exist yet?), because they use subtly different interfaces and invoke undefined behavior in subtly different ways. C++-style casts are useful only in that they provide something to grep for; good C++ code never casts anything — except the return value of malloc(), and that’s only because C++ took C’s nice “void *” semantics and suckified them.
I’ll agree that inheritance and cut-and-paste code are bad ideas. I’ll add virtual methods, function overloading, operator overloading, “float”, any use of NaN, unnamed namespaces and classes, “plain int” bit-fields, constructors that run before main() in what amounts to an arbitrary order, switch case fall-through, template specializations, mutable members, throwing exceptions, and passing non-POD objects by value.
At least C++0x officially condones “long long”. If only they hadn’t added three new string types at the same time…
Can someone tell me about “strong typedef”, I mean the ability to define a type having the same behavior of another one but consider as different type ?
Thanks You so much …
And, of course, it goes without saying, thanks for all the time and effort, Herb.
I still see so much newly-written code employing hand-coded loops [instead of STL algorithms], raw pointers and manual memory management [instead of smart pointers], overuse of the inheritance mechanism, copying-and-pasting code [instead of writing generic code using templates], choosing the wrong STL containers, using C-style casts [instead of C++ casts], etc. etc.
I’m not even talking about the special practices which are a pre-requisite for robust unit testing (simple interfaces, maintaining class invariants, RAII, etc.).
More beneficial than an early implementation of the new C++00X standard would be C++ programmers using more expertly the _existing_ standard.
When do you think we will be able to actually write and compile code using this new standard?
And how many years will take to rewrite crippled STL ?
I can’t compare it to well documented and intuitive .Net or QT without cry :-/
Now that C++0x is feature complete all the dangling pointers and all the esoteric constructs can make me the new King of Hill and there by saving my job for the next 10 years.
Herb, you have done a wonderful job. The time you invested as a convener is much appreciated.
Congratulations, Herb, to you personally and to the Committee!
It was a long and I hope enjoyable run (at least, much enjoyable for us, mailing list readers), and we are happy to finally see it came to real.
Many thanks to you guys, your efforts are very much appreciated!
Getting out of this chair, do you have any new project in mind?
Thanks for the time and energy you have invested in C++0x!
Great news ! All us C++ contractors now have a meal-ticket for life, clearing up the messes that will be created in this language. Thanks to Bjarne and the rest of the team; how about a paypal link on your site ? I definitely owe you a bung.
Thanks for the hard work as chair and keeping the community informed of the progress of our next standard. I overjoyed that concepts will make the final standard.
Thanks for all those years of effort, Herb. Very much appreciated.
Now we eagerly await 2009!
What’s wrong with \ as a namespace separator for PHP?
About time, only 3 or 4 years too late. The other languages are laughing at us. Except for PHP users who just got screwed with \ as a namespace separator.
It’s a moment of joy for us. So will C++0x be C++09. And when will we have TR2?
Best wishes to Herb.
Congratulations Herb. This is quite a milestone. Very nice job herding the cats over a multi-year period to bring this to fruition. I know it was by no means an effort of one person but still, good job and many will benefit from it.