C/C++ and Fortran

Originally posted by: Michael_Wong

The Library side brought about some of the most interesting changes. I already discussed the key discussions with respect to unifying the Asynchronous futures proposal in The View (or trip report) from the Oct 2009 C++ Standard meeting.

This resulted in a paper which will be published in the upcoming mailing (in about a week from now), which will show the approach on Asynchronous Call A Simple Asynchronous Call.

The key changes there were:

• A restoration of the variadic thread and async functions. This restoration is a consequence of analysis and request of the British Standards Institute.
• A convergence on the "as if a new thread" in the launching of asynchronous work. This change avoids undefined behavior arising from any delay in destroying thread-local variables, but requires careful implementation to avoid excessive overhead.
• Removal of the is_ready, has_exception, and has_value query functions. The presence of these function requires still other functions in the synchronous case. Evolution Working Group direction is that the complexity in interface is as yet unjustified, and prudence dictates a smaller initial interface.
• Unspecified behavior for the use of timed wait functions when the unique_future was created from a deferred async.
• The conversion from unique_future to shared_future will execute any deferred work.
• The use of an enum class to better clarify the launching policy.

The other papers which support this is a resolution of most of the futures issues from National Body comments in Issues on Futures (Rev. 1) . A future describes components that a C++ program can use to retrieve in one thread the result (value or exception) from a function that has run in another thread.

These components are not restricted to multi-threaded programs but can be useful in single-threaded programs as well.

The other resolved issues include:

• Supporting constexpr in the library properly fixing a number of issues: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/N2994.html.

• Clarifying use cases of std::forward: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html

• A set of small bug fixes and minor improvements to forward_list. It addresses all the issues in raised in LWG Issue 897, and several other matters. It is in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2988.pdf

• moves swap from the <algorithm> header to <utility> to address UK 300 because swap has become a common utility operation with several common idioms relying on it

• resolving a collection of issues with atomics in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html. Most of these issues are related to wording subtlties and wish for clarification from national body reviews.

• we added new type traits is_trivially_copyable, is_literal_type, is_nothrow_constructible, is_constructible, is_explicitly_convertible, underlying_type in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/N2984.html

• The adoption of N2554 (The Scoped Allocator Model) and N2525 (Allocator-specific Swap and Move Behavior) needed take account of the removal of Concepts from the Frankfurt meeting. It is in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf

Most of these are motivated by National Body comments from CD1. This shows the effort and focus of the committee during these periods as we continue to resolve the almost 600 comments that was received from the September 2008 CD1 draft.

There is now plan to issue a second draft for comment (post removal of Concepts, and with the fixes like above from CD1 comments). This will be CD2 and will be aimed for release after the next meeting in March 2010, in Pittsburgh hosted by Carnegie Mellon.

I will describe in another post more details on the schedule changes which is now clearer and I have updated in the C/C++ Standard hub