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.)
Sutter’s Mill 
Will C++0x become C++1x or even C++0A C++0B ?
You would absolutely need some method of incorporating the exception specification of a template parameter-dependent function (declexcept keyword, perhaps). Whether that would solve all the problems, I don’t know. But modern C++ coding styles are incompatible with Java’s exception-checking syntax (name every exception or a base class explicitly).
Is there an update to the “State of C++ Evolution” as in https://herbsutter.wordpress.com/2008/04/23/where-to-find-the-state-of-iso-c-evolution/ yet? the newest one I can find is for San Francisco: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html
C++ can throw at a low level and catch at the main loop, without the intermediate levels aware of the *type* of the exception.
Java requires one to update all intermediate layers with either “throws FooException” or write many exception chaining statements. Or just add “throws Exception” to all functions, which defeats the whole system.
As an example: suppose I have a three-tier application: Data Layer, Business Rules, and GUI. (This may be a simplification, but it will be enough to make my point)
Suppose the Data Layer uses a database for storage. Of course, it could be offline, so there is some “ConnectionException”.
Usually, I would want my GUI to pop up a message “Database offline”. The user can ring the DB admin, or correct it herself. When it has been corrected, the user tries again. The program itself doesn’t need to correct it.
Now imagine that due to a new requirement, the Data Layer has to throw a new exception.
In C++, the Business Layer doesn’t need to be updated at all. The new exception is propagated automatically.
In Java, all of the Business Layer needs to be updated. That’s a lot of manual work.
IMHO, that is the additional work that Florin was talking about.
SupposedToBeLocal should never be an exception to start with. Exceptions are for long range flow control, and for exceptional situations you can’t easily recover from.
In my programs, I usually have just one catch() statements: in the main loop.
For web services: in case of an exception during processing a request, log the exception and send an error reply. No need to try recovering.
For gui problems: pop up a message box with continue/quit options. User can try to recover.
For batch programs: write the offending record to a ‘failed’ file/table including error message, and continue with the next record. The user can check the failed list afterwards.
And so on.
If you want to force that the caller of C::foo() handles an exceptional situation, use return codes.
There is a reason why C# has both Double.Parse(string s) (returning double) which throws, and Double.TryParse(string s, out double d) (returning a bool).
So basically, your use of “throw SupposedToBeLocal();” should be refactored anyway.
There is no chance that compile-time specification checking will be in C++ as it is now.
For a starter, there are too many technical problems. What would be the specification of std::vector’s copy constructor? Or of any of algorithms from ?
Secondly, Java’s approach is not repeated in any language, and there is a reason for that. Read Anders Hejlsberg’s opinion at http://www.artima.com/intv/handcuffs.html or Bruce Eckel’s opinion at http://www.mindview.net/Etc/Discussions/CheckedExceptions . They are much better at writing than I am.
> That means the automatic way of C++ exception propagation was transformed into a manually one.
Explain, please.
I don’t see any sort of automatism that is lost when exceptions flow is under control.
Java does it right. C++ should do something similar to Java. In a statically typed language the compiler should force programmer to do the right thing whenever it can. I can’t tell you the number of times I’ve seen developers get nailed by an uncaught exception they either didn’t know about or that they forgot. If you’re lucky you catch it (no pun intended) in testing. If not …
e.g. in foo.cpp
struct SupposedToBeLocal { … };
void C::foo() { … throw SupposedToBeLocall(); … }
in bar.cpp
void D::bar() {
c->foo() ; // whoops!
}
Yeah, it’s sloppy, yeah the coder should have known better, but back in the real world there are deadlines and pressures to ship (or join the unemployment lines). Unfortunate code get’s written. The compiler can and should help.
Nickolas, the checked exception in Java is not a good idea.
It seems that some Java programmers wants run time checked exception like in C++, and some C++ programmers wants Java checked exceptions.
Why the Java technique is not a good one? Because each time you call a method that throws something, Java compiler force you to explicit caught or explicit throw that exception. That means the automatic way of C++ exception propagation was transformed into a manually one.
The only way to escape this problem is to throw a run time exception. And this is a little hack to stop Java complain.
I’m very glad to hear that there are some movements with exception specs, this thing really bothers me much.
They way exception specifications are implemented now is definitely wrong, but the idea of specs itself seems to be worthy. IMHO, it would be better not to through them away completely, but fix them up and make useful. Compile-time specification checking (as it is in Java) seems to be the very right thing. Is there a chance that exception specifications in C++ would evolve in this way?
Herb, it’s a shame you couldn’t have renamed unique_ptr to ptr while you were rightly doing that for future? I’m sure the reason is the name is used a lot already but….
Slightly related, I see Scott Myers was rightly complaining (if I may call it that) on groups.std.c++ about some of the inconsistencies still to be worked out. He makes some good points even if some appear to me at least to be a bit jonny come lately (like mine) although my points aren’t half as good as his so I’ll let him off! :)
He is asking about VLAs I see. Any comments on those yourself? I don’t think i ever needed them myself, I just thought I did like most features.
I myself would still love to see attributes dropped and some more keywords introduced instead. Danny K is talking about this currently. I know it breaks code, but “we” are too sensitive about keywords. A bit more unification with C++/CLI would have been nice perhaps. The abstract keyword for example for use on class or methods to avoid the ugly = 0 syntax? Though of course I’m sure others will remind me C++ will never be a prom queen no matter how much lipstick we graft onto it! Still, every little helps.
I am sorry Bill felt the need to quit as convener by the way. I know us “customers” push committee members all over the place in our contradictory moans so I hope he feels appreciated no matter what else happens instead. Thanks for volunteering again too if you do decide to do that.
On that note, does that mean we can now blow the schedule further to pieces and get Concepts, Modules, and Multi-methods back in, plus my own pet “fixes”! Pretty please ;)
Even if not, there is so much good stuff to put into C++ still and fix with it. I hope you committee guys aren’t just expecting to sit back and take it easy now and well, write a book or something? You are Mr Concurrency after all so I don’t see why you can’t do both quickly ;)
Even if a lot appears to be strained at the minute, I hope all this attention with C++ can keep things moving at a constant and steady ongoing pace. Maybe even bad publicity is better than none, but I wont promote that idea too strongly!
I’d heard a bit about mr Plauger stepping down. Which is too bad, but… done. After that, I had been worried what might become of the current standardization process, since wouldn’t the stepping-down thing also mean that there would be another delay and I understood that the comittee had already missed one ISO deadline. I’d love to just be able to use things like the delegating constructors and Unicode string literals and long longs in my cross platform code today. (Which is too idealistic, I’m sure it’ll take a few years for the Solaris and AIX compilers to catch up to the standard.) So I’ve begun to really dislike seeing any more apparent delays in the C++0X standardization process crop up. But I’m more optimistic now that with an experienced convener things will once again pick up and lead to a definite standard in the not too distant future.
std::async(..): fantastic.
Chance to have Herb Sutter back as chair: even better!
Thanks to P.J. Plauger for all his services.
@Clare: Oops. Fixed.
” I will probably volunteer again to replace him.”
Please do. I really hope someone as capable and experienced as you would take it up, as there’s seems so much anxious expectation on new C++(0x) features to be finalized and formally out in our hands.
Would that title be “October *2009*”?…