Tuesday, 07 December 2010
The November 2010 mailing for the C++ Standards Committee was published last week. This is the post-meeting mailing for the November 2010 committee meeting.
As well as the usual core and library issues lists, this mailing also includes an updated summary of the status of the FCD comments, along with a whole host of papers attempting to address some the remaining FCD comments and a new C++0x working draft.
To move or not to move
In my blog post on the October mailing, I mentioned that the implicit generation of move constructors was a big issue. I even contributed a paper with proposed wording for removing implicit move generation from the draft — with expert core wording guidance from Jason Merrill, this became N3216. My paper was just to give the committee something concrete to vote on — it doesn't matter how good your arguments are; if there isn't a concrete proposal for wording changes then the committee can't vote on it. In the end, the decision was that implicit move generation was a good thing, even though there was the potential for breaking existing code. However, the conditions under which move operations are implicitly generated have been tightened: the accepted proposal was N3203: Tightening the conditions for generating implicit moves by Jens Maurer, which provides wording for Bjarne's paper N3201: Moving Right Along. The proposal effectively treats copy, move and destruction as a group: if you specify any of them manually then the compiler won't generate any move operations, and if you specify a move operation then the compiler won't generate a copy. For consistency and safety, it would have been nice to prevent implicit generation of copy operations under the same circumstances, but for backwards compatibility this is still done when it would be done under C++03, though this is deprecated if the user specifies a destructor or only one of the copy operations.
Exceptions and Destructors
The second big issue from the
October mailing was the issue of implicitly adding
noexcept to destructors. In the end, the committee went
for Jens Maurer's paper N3204:
Deducing "noexcept" for destructors — destructors have the
same exception specification they would have if they were implicitly
generated, unless the user explicitly says otherwise. This will break
code, but not much — the fraction of code that intentionally
throws an exception from a destructor is small, and easily annotated
noexcept(false) to fix it.
There are 9 concurrency-related papers in this mailing, which I've summarised below. 8 of them were adopted at this meeting, and are now in the new C++0x working draft.
- N3188 - Revision to N3113: Async Launch Policies (CH 36)
It provides a clearer basis for implementors to supply additional launch policies for
std::async, or for the committee to do so in a later revision of the C++ standard, by making the
std::launchenum a bitmask type. It also drops the
std::launch::anyenumeration value, and renames
std::launch::deferred, as this better describes what it means.
The use of a bitmask allows new values to be added which are either distinct values, or combinations of the others. The default policy for
- N3191: C++ Timeout Specification
There are several functions in the threading portion of the library that allow timeouts, such as the
try_lock_untilmember functions of the timed mutex types, and the
wait_untilmember functions of the future types. This paper clarifies what it means to wait for a specified duration (with the xxx
_forfunctions), and what it means to wait until a specified time point (with the xxx
_untilfunctions). In particular, it clarifies what can be expected of the implementation if the clock is changed during a wait.
This paper also proposes replacing the old
std::chrono::monotonic_clockwith a new
std::chrono::steady_clock. Whereas the only constraint on the monotonic clock was that it never went backwards, the steady clock cannot be adjusted, and always ticks at a uniform rate. This fulfils the original intent of the monotonic clock, but provides a clearer specification and name. It is also tied into the new wait specifications, since waiting for a duration requires a steady clock for use as a basis.
- N3192: Managing C++ Associated Asynchronous State
This paper is a revision of N3129: Managing C++ Associated Asynchronous State from the August mailing. It is a minor revision to the previous paper, which clarifies and simplifies the proposed wording.
This paper tidies up the wording of the functions and classes related to the future types, and clarifies the management of the associated asynchronous state which is used to communicate e.g. between a
std::futurethat will receive the result.
- N3193: Adjusting C++ Atomics for C Compatibility
It drops the C compatibility header
<stdatomic.h>, and the macro
_Atomic, and loosens the requirements on the
atomic_xxxtypes — they may be base classes of the associated
atomic<T>specializations, or typedefs to them.
- N3194: Clarifying C++ Futures
There were a few FCD comments from the US about the use of futures; this paper outlines all the issues and potential solutions. The proposed changes are actually fairly minor though:
share()member function for easy conversion to the corresponding
- Accessing a
falseis now encouraged to throw an exception though it remains undefined behaviour;
atomic_futureis to be removed;
packaged_tasknow has a
valid()member function instead of
operator boolfor consistency with the future types.
A few minor changes have also been made to the wording to make things clearer.
- N3196: Omnibus Memory Model and Atomics Paper
This paper clarifies the wording surrounding the memory model and atomic operations.
- N3197: Lockable Requirements for C++0x
This paper splits out the requirements for general lockable types away from the specific requirements on the standard mutex types. This allows the lockable concepts to be used to specify the requirements on a type to be used the the
std::unique_lockclass templates, as well as for the various overloads of the wait functions on
std::condition_variable_any, without imposing the precise behaviour of
std::mutexon user-defined mutex types.
- N3209: Progress guarantees for C++0x (US 3 and US 186)(revised)
This paper is a revision ofN3152: Progress guarantees for C++0x (US 3 and US 186) from the October mailing. It is a minor revision to the previous paper, which extends the proposed wording to cover
compare_exchange_weakas well as
The FCD does not make any progress guarantees when multiple threads are used. In particular, writes made by one thread do not ever have to become visible to other threads, and threads aren't guaranteed ever to actually run at all. This paper looks at the issues and provides wording for minimal guarantees.
- N3230: Constexpr Library Additions: future
This paper has not yet been accepted by the committee. It adds constexpr to the default constructors of
shared_future, so that they can be statically initialized.
Other adopted papers
Of course, the committee did more than just address implicit move, exceptions in destructors and concurrency. The full minutes are available as N3212 in the mailing. Here is a quick summary of some of the other changes made:
- Library functions that don't throw exceptions have been changed to
- The ratio arithmetic facilities have been changed to allow
libraries to try and give the correct result if the result is
representable, but the intermediate calculations may overflow
- New functions have been added to retrieve the current new handler, terminate handler or unexpected handler (N3189)
- Alignment control is now done with the
alignaskeyword, rather than an attribute (N3190)
- Virtual function override control is now done with keywords
(including the first context sensitive keywords:
final) rather than attributes (N3206)
For the remaining changes, see the full minutes.
FCD comment status
The count of unresolved FCD comments is dropping rapidly, and now stands at 75 (out of 564 total), of which only 56 have any technical content. See N3224: C++ FCD Comment Status from the mailing for the full list.
If you have any opinions on any of the papers listed here, or the resolution of any NB comments, please add them to the comments for this post.