C++0x news

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Mar 13 12:53:30 PST 2010


Executive summary: C++0x will in all likelihood be C++11, export finally 
gets the axe (thank God), exception specifications get deprecated, 
noexcept gets added... well pretty much what D does :o).

Andrei

-------- Original Message --------
Subject: 	[herb_sutter] Trip report: March 2010 ISO C++ Meeting
Date: 	Sat, 13 Mar 2010 19:55:04 +0000
From: 	Herb Sutter <hsutter at microsoft.com>
Reply-To: 	herb_sutter-owner at yahoogroups.com
To: 	herb_sutter at yahoogroups.com <herb_sutter at yahoogroups.com>



Here's the link to the full blog post:
http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ 

<http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/>

I've pasted the post below, but depending on the vagaries of Yahoo
Groups and the email format you selected, quotes and graphics and such
may not format correctly. Enjoy.

Herb

Trip Report: March 2010 ISO C++ Standards
Meeting<http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ 

<http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/>>

March 13, 2010 by Herb
Sutter<http://herbsutter.wordpress.com/author/herbsutter/
<http://herbsutter.wordpress.com/author/herbsutter/>>

[Note: I usually post trip reports after the public post-meeting mailing
goes live a few weeks after the meeting, so that I can provide links to
minutes and papers. This time, I wanted to post the report right away to
share the news. If you're interested in the post-meeting papers,
including the official minutes, watch the 2010 papers
page<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/>> which is
where they will appear in a few weeks.]

The ISO C++ committee met in Pittsburgh, PA, USA on March 8-13, 2010,
hosted by the CERT Software Engineering
Institute<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2956.pdf
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2956.pdf>> at
Carnegie Mellon University<http://www.cmu.edu/index.shtml
<http://www.cmu.edu/index.shtml>>. As usual, about 50 experts attended,
and we had eight official national body delegations from Canada,
Finland, France, Netherlands, Spain, Switzerland, United Kingdom, and
United States.

[IMG_0396]The meeting just concluded a few minutes ago (yes, the
meetings run through Saturday afternoon). Here are some highlights of
what happened today, which was another landmark in the progression of
the C++0x standard.

Approved Final Committee Draft (FCD) for C++0x

The biggest news is that this afternoon we voted in the final remaining
feature changes to C++0x, and to much applause then unanimously approved
the text for international ballot as a Final Committee Draft (FCD). FCD
means that, assuming no surprises, we intend to do only bug fixes and
editorial corrections for the next year or so, and then ballot a final
standard. If we can do that, assuming all goes well, C++0x could
officially be published as soon as next year as ISO C++ 2011, and we can
stop with the "x-is-hex" jokes and just start calling it C++11.

This is a big milestone, and it was achieved thanks to removing a couple
of controversial features last summer and a whole lot of work by the ISO
C++ committee members over the past six months in particular. That work
includes countless hours spent between our full face-to-face meetings at
face-to-face ad-hoc meetings to swat library bugs, teleconferences on
resolving core language questions, and triple-digit person-hours
invested in four teleconferences during December-February purely about C
and C++ compatibility that have greatly helped to identify and attempt
to resolve minor areas of divergence between the C++0x draft standard
and the C1x draft standard (as both are now in progress; C1x is
targeting completion and publication in 2012).

All in all, your committee members have put in an enormous amount of
effort to bring this in, and the draft is in far better shape for this
meeting than anyone could have expected last summer. For comparison, in
my and several others' opinions, it's in better shape than the FCD of
the C++98 standard.

Since we're closing down this round of standardization, we didn't make
many exciting technical changes. Here are two technical highlights of
the meeting that are likely of general interest, finally adopting
changes we've contemplated before.

Removed Export Template

As I reported after the last meeting
(here<http://herbsutter.wordpress.com/2009/10/23/deprecating-export-considered-for-iso-c0x/ 

<http://herbsutter.wordpress.com/2009/10/23/deprecating-export-considered-for-iso-c0x/>> 

and
here<http://herbsutter.wordpress.com/2009/11/11/trip-report-october-2009-iso-c-standards-meeting/ 

<http://herbsutter.wordpress.com/2009/11/11/trip-report-october-2009-iso-c-standards-meeting/>>), 

the committee considered the question of whether to deprecate, remove,
or leave in the "export template" feature.

For context, the only reason we're even considering this is because
Edison Design Group (EDG), the only company to ever implement export, is
recommending export be removed or deprecated. Recall that back in the
1990s the committee originally voted the feature in over EDG's
objections in the first place, then in the late 1990s and early 2000s
EDG graciously and gallantly went on to invest enormous effort to
implement the feature in order to conform to the standard, and so the
committee was loath to punish them again by now removing the feature on
them. However, given the passage of time, EDG reports that their
experience in the field has been that nearly no one actually uses the
feature, and that it would be right (and okay with EDG) to deprecate or
remove it.

At our previous meeting, the general sentiment was in favor of
deprecation only. However, at this meeting EDG reported that they would
prefer the feature to be removed rather than just deprecated, because a
deprecated feature is still part of the standard and required for
conformance. By removing it from C++0x, it removes the maintenance
burden of being forced to support export indefinitely to maintain full
standards conformance (though of course EDG will continue to support it
as an extension in their compiler front end for however long seems right
based on their own customers' demand).

The committee agreed, and today voted to remove export entirely from
C++0x. The "export" keyword is still reserved for future use, but has no
defined meaning in the C++0x standard.

Deprecated Exception Specifications, Added noexcept

As also considered at our previous meeting, this week we went ahead and
deprecated throw-specifications (e.g., throw(), throw( Base, Derived1
)). For rationale, see the two background references referred to in the
proposal, one of which is an article by me:

* H. Sutter. "A Pragmatic Look at Exception
Specifications"<http://www.gotw.ca/publications/mill22.htm
<http://www.gotw.ca/publications/mill22.htm>>
* Boost. "Boost Exception Specification
Rationale"<http://www.boost.org/development/requirements.html#Exception-specification 

<http://www.boost.org/development/requirements.html#Exception-specification>>

As noted in the second reference, "A non-inline function is the one
place a 'throws nothing' [i.e., throw()] exception-specification may
have some benefit with some compilers." Because this would have some
utility, there is a replacement for empty exception-specifications...
the noexcept keyword, which has the basic use syntax "void f() noexcept
{...}". It optionally takes a compile-time constant true/false
expression that if true means the noexcept is in force, which helps
libraries to write efficient overloads. This feature will be written
about for years to come, but that's the basic idea.

Here's the concise summary from the core working group report by Steve
Adamczyk (of EDG fame and longtime core working group chair):

We discussed two things related to exception specifications: noexcept
(N3050), and deprecating exception specifications (N3051). There was
some spirited discussion of what happens when you violate a promise not
to throw. In the end, we decided that in such a circumstance terminate()
gets called, and it's unspecified whether any cleanup is done for local
variables between the throw point and the point of the violated
noexcept. It's believed that for efficient implementations of exception
handling a noexcept will not add any overhead and will not restrict
optimization opportunities.

The old-style exception specifications, including the throw() form, will
now be deprecated. The library specification needs to be updated to use
noexcept instead, and that won't happen at this meeting.

Note that the decision to call terminate() is not final and alternatives
will be considered at future meetings. There was general (but not
universal) agreement that the program should not be allowed to continue
executing if a noexcept is violated because in that case the program
will almost certainly be in a corrupt state, and so the consensus was in
favor of guaranteeing to call terminate() instead of allowing arbitrary
undefined behavior, but it's possible that a comfortable middle ground
between those two options may yet be found.

Looking Forward

We wrapped up with a
presentation<http://www.facebook.com/photo.php?pid=3554907&id=835813469
<http://www.facebook.com/photo.php?pid=3554907&id=835813469>> of the
scheduled dates and locations for the next few ISO C++ standards
committee meetings (meeting information link included where available):

* August 2-7, 2010: Rapperswil,
Switzerland<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3016.pdf 

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3016.pdf>>
* November 8-13, 2010: Batavia, Illinois,
USA<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3015.pdf
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3015.pdf>>
* March 21-26, 2011: Madrid, Spain

Finally, here's a copy of summary slide I presented, which will also be
in the post-meeting mailing. Here's to C++11 (we hope)!

[Pittsburgh slide.jpg]

[Non-text portions of this message have been removed]

__._,_.___
Reply to sender <mailto:hsutter at microsoft.com?subject=Trip report: March
2010 ISO C++ Meeting> | Reply to group
<mailto:herb_sutter at yahoogroups.com?subject=Trip report: March 2010 ISO
C++ Meeting> | Reply via web post
<http://groups.yahoo.com/group/herb_sutter/post;_ylc=X3oDMTJvdmdyajlsBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BG1zZ0lkAzE5OARzZWMDZnRyBHNsawNycGx5BHN0aW1lAzEyNjg1MTA3OTE-?act=reply&messageNum=198> 

| Start a New Topic
<http://groups.yahoo.com/group/herb_sutter/post;_ylc=X3oDMTJlOW5kbG1xBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTI2ODUxMDc5MQ--> 


Messages in this topic
<http://groups.yahoo.com/group/herb_sutter/message/198;_ylc=X3oDMTMyMnM3ZHZrBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BG1zZ0lkAzE5OARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzEyNjg1MTA3OTEEdHBjSWQDMTk4> 

(1)
Recent Activity:

      * New Members
 
<http://groups.yahoo.com/group/herb_sutter/members;_ylc=X3oDMTJmYThjbjQ1BF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzEyNjg1MTA3OTE-?o=6>
        2

Visit Your Group
<http://groups.yahoo.com/group/herb_sutter;_ylc=X3oDMTJlMTFzc2dzBF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTI2ODUxMDc5MQ--> 


To unsubscribe, send an empty email to
mailto:herb_sutter-unsubscribe at yahoogroups.com.
Yahoo! Groups
<http://groups.yahoo.com/;_ylc=X3oDMTJkYjByZnU0BF9TAzk3MzU5NzE0BGdycElkAzE0NTE2MTAEZ3Jwc3BJZAMxNzA1MDA2Nzg4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMjY4NTEwNzkx> 


Switch to: Text-Only
<mailto:herb_sutter-traditional at yahoogroups.com?subject=Change Delivery
Format: Traditional>, Daily Digest
<mailto:herb_sutter-digest at yahoogroups.com?subject=Email Delivery:
Digest> • Unsubscribe
<mailto:herb_sutter-unsubscribe at yahoogroups.com?subject=Unsubscribe> •
Terms of Use <http://docs.yahoo.com/info/terms/>
.

__,_._,___



More information about the Digitalmars-d mailing list