C/C++ and Fortran

Originally posted by: Michael_Wong

All, an unprecedented meeting indeed.

At this meeting in Pittsburgh, on March 13, 2010, we voted to dispatch a Final Committee Draft (FCD) according to this motion:
Motion 1

Move we request the Convener to advance the Working Paper as amended by the foregoing motions to Final Committee Draft (FCD) Status, forward that draft to SC22 for FCD Ballot, and appoint a review committee consisting of Steve Adamczyk and Howard Hinnant to approve the Project Editor's updates to the Working Paper.

What this means is that this is the accumulated integrated work of all the features for the new Standard and will be made public, and this will now be submitted for National Ballot for the next 5 months. Comments will be restricted to existing content of the draft. They will be evaluated at the next meeting in August at Rapperswil. This is your chance to make any changes as you read over the combined work of this draft. We already know of a number of issues but you can still open them. This will put us on tract for Final Draft International Standard (FDIS) for Mar 2011.

It was not without controversy. This was the most controversial
Paper N3050, Allowing Move Constructors to Throw (Rev. 1)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html
(not accessible yet until this paper is published to the site in 2 weeks)
started off as a favorable wish to resolve a problem, noticed by a few clever people was the most controversial, purely because as a side effect of this paper. It presented a noexcept syntax as an optimization hint to the compiler that this function will not throw. to resolve the problem of move constructors that may throw.

Quoted from the paper:
The only impact of such an exception-specification is this: if a function decorated with noexcept(true) throws an exception, the implementation is required to call std::terminate() but it is implementation-defined whether the stack is unwound

It effectively still keeps most of the optimization, but closes a security hole by making sure it calls terminate.
The competing and the original authors' proposal would have asked that this goes to undefined behavior, core dump, delivers 1600 tennis balls to your door, anything. This is because this is effectively what would happen if your implementation were to not wrap any exception mechanism around the code. The benefit is that it would improve performance but it leaves a potential security hole.

The "discussion" lasted most of the afternoon, but several people were dead-set against either position. This is rare but could happen and it is why it is troubling because this makes it not a consensus.

At the end, the majority did vote to support this, but because of the strong objection to this proposal, we wanted ensure a core defect is opened (and probably a National Body Comment) to continue exploration after the FCD is issued. The great fear was that this issue would stop people from agreeing to issue a FCD.
Indeed, there were opinions expressed that we should delay it because many new and significant changes were just put in during this meeting. In the end, it did not obstruct the FCD. I didn't think we would get here last year when I was at the last meeting. But hey, progress moves forward when determined people get together.

Aside from this, the most interesting update is a revamping of the familiar lvalue and rvalue system. The new system will take some explaining in a future article. The reason for this is because rvalue reference objects now can behave in a decidedly non rvalue way, including being polymorphic, which the old rvalues could not be, among other quirks.

As quoted from the Formal report:
All expressions are now divided into three "value categories":

* "lvalues" are the same as what's meant traditionally by lvalue.
* "xvalues" are objects created by rvalue reference operations (sometimes previously called "rvalue reference objects"). The "x" can be for "eXpiring value" or a cross between lvalues and rvalues.
* "prvalues" are the new name for traditional rvalues (i.e., excluding the xvalue cases). The "p" is for "pure rvalue".

There are two compound categories:

* "glvalues" are lvalues and xvalues. These are things that have dynamic type and object identity.
* "rvalues" are xvalues and prvalues. These are (as now in the draft) things that are potentially movable.

I will show much more on this in the future.