March 2010 C++ Standards Committee Mailing

Thursday, 08 April 2010

The March 2010 mailing for the C++ Standards Committee was published last week. This is the post-meeting mailing for the March 2010 committee meeting, and contains the C++0x Final Committee Draft, which I blogged about last week.

There are 6 concurrency-related papers (of which my name is on two), which I summarize below:

Concurrency-related papers

N3057: Explicit Initializers for Atomics

This paper proposes new initializers for atomic variables, providing a means of writing code which can be compiled as either C or C++. e.g.

void foo()
{
    atomic_int a=ATOMIC_VAR_INIT(42); // initialize a with 42
    atomic_uint b;                    // uninitialized
    atomic_init(&b,123);          // b now initialized to 123
}

N3058: Futures and Async Cleanup (Rev.)

This is a revision of N3041 to resolve many of the outstanding issues with futures and async. Mostly it's just wordsmithing to tidy up the specification, but there's a few key changes:

• Defined behaviour for the wait_for() and wait_until() member functions of std::future, std::shared_future and std::atomic_future when used with std::async and a launch policy of std::launch::sync. The return value is now a value of the new std::future_status enumeration, and can be std::future_status::ready if the future becomes ready before the timeout, std::future_status::timeout if the wait times out, or std::future_status::deferred if the future comes from a call to std::async with a launch policy of std::launch::sync and the function associated with the future hasn't yet started execution on any thread.
• The wording for std::async adopts the same wording as std::thread to clarify the copy/move and perfect forwarding semantics of the call.

N3069: Various threads issues in the library (LWG 1151)

This is a revision of N3040, and highlights which operations through iterators constitute accesses and data races, and explicitly allows for synchronization by writing and reading to/from a stream.

N3070: Handling Detached Threads and thread_local Variables

This is a hugely simplified replacement for my previous paper N3038. Rather than creating contexts for thread_local variables, this paper proposes new member functions for std::promise and std::packaged_task to allow the value to be set at the point of call, but threads waiting on associated futures to be woken only after thread_local variables have been destroyed at thread exit. This means that you can now safely wait on a future which is set in such a fashion when waiting for a task running on a background thread to complete, without having to join with the thread or worry about races arising from the destructors of thread_local variables. The paper also adds a similar mechanism for condition variables as a non-member function.

N3071: Renaming launch::any and what asyncs really might be (Rev.)

This is a revision of N3042 proposing renaming std::launch::any to std::launch::sync_or_async. This paper was not approved.

N3074: Updates to C++ Memory Model Based on Formalization

This is a revision of N3045. This paper proposes some changes to the wording of the memory model in order to ensure that it means what we intended it to mean.

Other Papers

There's several non-concurrency papers in the mailing as well as the standard set (working draft, agenda, issues lists, etc.). The most significant of these in my view are the following 3 papers. Check the mailing for the full set.

N3050: Allowing Move Constructors to Throw (Rev. 1)

This paper adds the new noexcept keyword to C++. This is used in place of an exception specification. On its own it means that the function does not throw any exceptions, but it can also be used with a boolean constant expression where true means that the function doesn't throw, and false means that it might. e.g.

void foo() noexcept;        // will not throw
void bar() noexcept(true);  // will not throw
void baz() noexcept(false); // may throw

If a noexcept exception specification is violated then std::terminate() is called.

The primary benefit from the boolean-constant-expression version is in templates, where the boolean expression can check various properties of the template parameter types. One of the things you can check is whether or not particular operations throw, e.g. by using the new has_nothrow_move_constructor type trait to declare the move constructor for a class to be noexcept if its class members have non-throwing move constructors:

template<typename T>
class X
{
    T data;
public:
    X(X&& other)
        noexcept(std::has_nothrow_move_constructor<T>::value):
        data(std::move(other.data))
    {}
};

N3053: Defining Move Special Member Functions

This proposal ensures that user-defined classes have move constructors and move assignment operators generated for them by the compiler if that is safe. Explicitly declaring a copy or move constructor will prevent the implicit declaration of the other, and likewise for copy and move assignment. You can always request the default definition using the = default syntax.

This means that lots of user code will now be able to readily take advantage of move semantics with a simple code change or even just a recompile. This can potentially be of major performance benefit.

N3055: A Taxonomy of Expression Value Categories

This paper nails down the true distinctions between lvalues, rvalues and rvalue references. It provides a new set of names to identify the distinct categories of values in C++ — lvalues and rvalues we already have, but now there's xvalues, prvalues and glvalues too. This categorization allows for better specification of when things can bind to lvalue references or rvalue references, when the compiler can eliminate copies or moves.

Please comment on the FCD

The purpose of the C++0x Final Committee Draft is to get comments prior to publication to ensure the final C++0x standard is as defect free as possible. This opportunity is only available for a limited time, so please comment on the FCD.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: C++0x, C++, standards, concurrency
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Design and Content Copyright © 2005-2024 Just Software Solutions Ltd. All rights reserved. | Privacy Policy