The ISO C++ committee met in Toronto on July 15-20. Here’s a quick summary of what we did, and information about upcoming meetings.
Features voted into draft C++0x
enum class (N2347)
This is an extension from C++/CLI that allow writing enums that has a predictable size and underlying type, has its own scope (to the enumerators don’t get injected into the enclosing scope where they can conflict with similar names), and doesn’t have a nasty implicit conversion to int (or anything else). The proposal was written by David Miller, myself, and Bjarne.
Saving exceptions (N2179)
Added language and library support for saving an exception: This feature is useful in plain old sequential code if you want to catch and store an exception to be rethrown later. But it’ll be especially useful in concurrent code, so that we can catch an exception and transport it across threads (e.g., when waiting on an asynchronous function call).
constexpr (N2235 and N2349)
This feature permits generalized constant expressions — or, in English, being able to write your own compile-time constants that really act like compile-time constants. To illustrate, here’s one simple example from the paper:
constexpr int square(int x) { return x * x; }
What’s the point? Now if you call square() with an argument that is a compile-time constant, then the result of calling square() is still a compile-time constant, and you can use it anywhere you can use compile-time constants, such as specifying the length of an array:
float arr[ square(9) ]; // ok, array of length 81
Note that the above is not a C99 variable length array. It’s a normal fixed-size array, but we have more flexibility and convenience in specifying its size.
See the linked paper for more details and examples. And to see how this new language feature is immediately also being used in the C++ standard library, here’s your source: N2349, "Constant Expressions in the Standard Library — Revision 2."
decltype (N2343 and N2194; for discussion see N2115 and N1978)
The decltype feature lets you get the type of an expression, so that you can do things with the type (e.g., declare more variables of that type) without knowing in advance what the type is or how to spell it.
This is a great boon to generic programming with templates, and without the runtime cost of reflection in other languages. For example, say that you’re handed an iterator, and you want to know what type it refers to. Today, you need to ask the iterator for its value_type, which is a manual "traits" convention everyone is expected to follow when writing and using iterators:
template<typename Iter>
void f( Iter it ) {
Iter::value_type v = *it;
…
}
With decltype, we could instead write:
template<typename Iter>
void f( Iter it ) {
decltype(*it) v = *it;
…
}
Are you curious to see how decltype is being used in the C++0x standard library itself? Here’s the paper for you: N2194, "decltype for the C++0x Standard Library."
alignof (N2341)
A nice portable way to get aligned storage and inquire about the alignment requirements of types without performing system-dependent backflips.
=default and =delete (N2346 and N2292)
If you’ve ever wished you could control the four default special member functions (default constructor, copy constructor, copy assignment, and destructor) and especially how they’re inherited from base classes, this is the paper for you.
How could these be useful in the C++0x standard library itself do you ask? Here’s where to find the answer: N2292, "Standard Library Applications for Deleted Functions."
Some other approved features
- N2340 "C99 Compatibility : _ _ func _ _ and predeclared identifiers (revision 2)"
- N2342 "POD’s Revisited; Resolving Core Issue 568 (Revision 5)"
- N2293 "Standard Library Applications for Explicit Conversion Operators"
- N2348 "Wording for std::numeric_limits<T>::lowest()"
- N2350 "Container insert/erase and iterator constness (Revision 1)"
- N2351 "Improving shared_ptr for C++0x, Revision 2"
- N2299 "Concatenating tuples" (except change the name of the four functions named concatenate to tuple_cat)
- N2007 "PROPOSED LIBRARY ADDITIONS FOR CODE CONVERSION" (hey, don’t blame me for screaming, that’s the title…)
- N2308 "Adding allocator support to std::function for C++0x" (except change the pass-by-value Allocator argument to pass-by-const-reference)
- N2321 "Enhancing the time_get facet for POSIX® compatibility, Revision 2"
- N2353 "A Specification for vector<bool>" into the C++0X Working Paper. (After all, no meeting would be complete without some discussion of vector<bool>…)
Next Meetings
Here are the next meetings of the ISO C++ standards committee, with links to meeting information where available.
- October 1-6: Kona, Hawaii, USA [N2289]
- February 24-29, 2008: Bellevue, Washington, USA
- June 8-13, 2008: Sophia Antipolis, France
The meetings are public, and if you’re in the area please feel free to drop by.
Oops, sorry, I hadn’t notice that this post had been written one year ago.
N2348, N2350, N2351, N2353 also link with closed Dinkumware wiki.
“Next Meetings …
February 24-29, 2008: Bellevue, Washington, USA
June 8-13, 2008: Sophia Antipolis, France”
Maybe 2009?
Thank you for observation.
Will the __func__ declarations (N2340) be required to use unmangled function names? If memory serves, the current state of the art in g++ uses mangled named, and that’s particularly unhelpful when generating trace log messages.
Is there anything similar proposed for class and namespace name constants? For a function in a class, is it the simple function name, or the fully qualified namspace::class::function name?
(And now that I’ve fixed my profile info) The link to N2346 is pointing to the dinkumware wiki, rather than the open-std.org site.
Also, when would I use =delete when I can use class X : private boost::non_copyable or a similar parent class to achieve the same effect? The non_copyable parent style means I don’t need to try to get the operator= overload syntax right, and it ensures that no copy constructor will compile at the same time. Is there some other case where I might want to use =delete instead?