On Sun, Sep 28, 2014 at 5:17 PM, Ed Smith-Rowland <3dw4rd@verizon.net> wrote:
On 08/14/2014 07:37 PM, Nelson, Clark wrote:
I have made a few minor revisions since N4030.

The redlining in the document is relative to the published SD-6; I think
that's the way we'll want to publish it. But here is what I've changed
recently:

In response to Ed Smith-Rowland's question about <optional> vs.
<experimental/optional> I updated the __has_include example. Of course it's
just an example, but I think it's more helpful now than it was.

In response to Walter's question about the "policy" for the C++14 table, I
minimally tweaked the text. :-)

In response to Richard's question/complaint, I deleted "has" from the macro
names for new features added by LWG issues.

There are sentences in the rationale section about features removed from
C++14 to a TS; I have changed them from editorial notes to plain old text.
(I don't know what's going to happen with the array extension TS, but it is
still an official project with an official number; hopefully something will
come of it.)


This still needs work in three areas:

1. We need introductory text and rationale for __has_cpp_attribute.
(Richard?)

2. We need to approve what we want to do about the LWG issues that Alisdair
brought up.

3. We need to make final determinations about shared_mutex.

--
Clark Nelson            Vice chair, PL22.16 (ANSI C++ standard committee)
Intel Corporation       Chair, SG10 (C++ SG for feature-testing)
clark.nelson@intel.com  Chair, CPLEX (C SG for parallel language extensions)


_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features
I apologize for sending this so late but I thought I had lost some notes regarding C++98 and C++11.
I collected some thoughts on "finishing" these areas if that is desired.

Here are some macros to finish-out C++11:

C++11
-----
N2439    __cpp_reference_qualifiers    200710    This has library usage

ref_qualifiers, to match the name of the grammar term?
 
N2756    __cpp_nsdmi    200809    Hate to spell this out :-(

NSDMI is GCC terminology; the standard calls these "brace-or-equal-initializers for non-static data members". My preferred terminology (with Project Editor hat on) is "default initializers". But...

    __cpp_aggregate_default_initializers        Or this, borrowed from CMake?

... we already have __cpp_aggregate_nsdmi, which is ... presumably ... what CMake means by this?

If we had a time machine, I'd like __cpp_default_initializers == 200809L here and __cpp_default_initializers == 201304L for N3653. As things stand, the most consistent thing is probably '__cpp_nsdmi'.
 
N1986    __cpp_delegating_constructors    200604    Users can migrate from initializer functions
N2540    __cpp_inheriting_constructors    200802    Ditto
N2930    __cpp_range_based_for_loops    200907   

Seems a bit wordy. __cpp_range_for ?
 
N2672    __cpp_initializer_lists    200806   

Some popular C++ compilers still don't support all these.
It doeas add a few more macros but it finishes C++11.
Other compilers may emerge that need to "work their way up" through these features.
I could go either way on this - I know some don't want to clutter up compilers with lots of macros.


C++98
-----
    __cpp_exceptions    199711L
   
    __cpp_run_time_type_id    199711L

I'd prefer __cpp_rtti

Rationale for __cpp_exceptions and __cpp_run_time_type_id:
Several compilers exist that allow the user to turn these features off with a macro or a compiler switch.
Providing these macros enhance portability of such code that uses macros to change code depending on availability of these features.

I just used the date standard when these were added to C++98 rather than try to dig up old papers.


_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features