The summer 2011 ISO C++ meeting was held on August 15-19 in Bloomington, Indiana, USA on the wonderful Indiana University campus. The minutes will be available at the 2011 papers page in a couple of weeks.
As previously announced, C++11 was unanimously approved just days before the standards meeting, so this was the first post-C++11 meeting. As planned, at this meeting we focused on processing some bug reports (defect reports, aka DRs) and have some initial discussion of the ‘what’s next’ variety. As expected, no decisions were made about whether we should consider new language extensions soon — that discussion will likely happen at our next meeting in February.
The big news out of last week’s meeting was on the standard library side: There was a clear decision that the library working group is ready to consider new library extensions, starting with the file system library proposal that was already accepted for post-C++11. The following announcement and instructions were read into the minutes:
The C++ committee Library Working Group welcomes proposals for library extensions which will be considered starting in the February 2012 meeting. We have not yet set out an overall timeline for future library extensions, but are ready to consider new proposals at this point.
To increase the chances of your proposal being accepted by the committee, we strongly recommend that a committee member willing to champion your proposal (this could be you yourself, or a delegate) attend upcoming meetings to help shepherd your proposal through the process.
It’s possible that this will take the form of a second library extensions technical report along the lines of the very successful Library Extensions Technical Report 1 (aka TR1). Whatever the form, it’s clear that the first order of business besides maintenance of the C++11 standard will be a new round of extensions to the C++ standard library.
Personally, I think that’s exactly what needed to happen at this meeting, and I’m very happy to see it take place. ASIO or thread pools, anyone? Maybe parallel algorithms, and concurrent containers? Stay tuned.
Looking forward
It’s our tradition to schedule one meeting a year outside the continental United States, and preferably outside North America, because this helps international participation by making it easier for people from all parts of the world to attend. Next year, as we’ve done before, this “un-American” meeting will be the Kona meeting, which is closer for folks in eastern Asia and Australia who may wish to attend.
Here are the planned dates and locations for upcoming ISO C++ standards committee meetings:
- February 6-10, 2012: Kona, HI, USA
- August or October, 2012: Portland, OR, USA
Sutter’s Mill 
@Derek: Go ahead and write a proposal for it. ;) (Probably along with a prototype implementation, of course)
The problem is that it’s a huge task, it’s really difficult to make something that’s both usable and not platform-dependent.
I’ve read on several occasions that Boost wouldn’t mind having a GUI library. It’s just that no one has offered to make one. Presumably the same for the standards committee. :)
No chance to see any UI type of stuff making it in the library one day? We UI developers are having a hard time dealing with antiquated imperative UI paradigms (MFC etc al.).
Is something like Intel’s TBB being considered? (/smarter/ parallel algorithms, + thread pool.) Would they share?
“ASIO or thread pools, anyone? Maybe parallel algorithms, and concurrent containers?” I can get those from Boost. Know what I can’t get from Boost?
*Modules*. Get on it. That’s something that should have been worked out for C++0x, but it was pushed off thanks in part to Concepts. A feature that was culled due to the need to get the spec out on time.
Yes, library stuff is important. But not as important as getting the final rough spots of the language ironed out. What we need is some compiler developer to go and make modules actually work, implement them, and then advertise it as a unique feature. Then, you’ll see how quickly it gets standardized when you cut compile times down by 2-3 orders of magnitude.
“ASIO or thread pools, anyone? Maybe parallel algorithms, and concurrent containers?”
Yes, please. All of that ;). Other good candidates: boost::variant and boost::optional.