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