On Sun, Sep 28, 2014 at 5:17 PM, Ed Smith-Rowland <3dw4rd_at_[hidden]>
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_at_[hidden] Chair, CPLEX (C SG for parallel language extensions)
>
>
>
> _______________________________________________
> Features mailing listFeatures_at_[hidden]://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_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>
>