Is SD-6 implemented by any of the compiler implementations?
If yes, no you know which ones?
I'm going to jump straight to the meta-question: Is there anything that can
and should be done to make it easier to find which compilers implement SD-6?
I think that is really a question for Herb:
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
I have had some experience suggesting that the WebEx invitation message
(below) isn't always by itself an effective way to announce a meeting. So
I'm sending another message to try to be sure everyone sees this
information.
Monday we will be reviewing the latest draft of SD-6. I'm hoping we will
I think the correct production should be:
has-attribute-expression:
__has_cpp_attribute ( attribute-token )
Thoughts?
Um, yeah, that seems right.
I guess we now have proof that Richard and Jens and John and I are all human.
:-/
Thanks for catching that, Aaron.
Clark
I said previously that I thought we would be ready to revise the SD-6 on
isocpp.org before the Urbana meeting, and I still think that -- the text is
all but ready now. But in thinking about the process of publishing the
revision, I had a new thought.
I think it would be a good idea to have the
Here is the updated draft, hopefully ready for formal publication on
isocpp.org.
Does anyone have any comment on whether we should publish before or after
the Urbana meeting? Please see the Formally revising message I posted
Tuesday for brief discussion.
I made a few changes we did not discuss
I have finally gotten around to updating SD-6 on isocpp.org:
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
What's up there now differs from N4200 in just a few minor ways (according
to my intention and knowledge):
1. An updated document date and history.
2. A
That does not sound entirely sane to me: I think you're suggesting
that a programmer would duplicate some set of numeric literals, just
so they could put digit separators in one copy of them. The risk of
the two copies becoming out-of-sync seems like sufficient
justification for any
I see portability as the main goal with SD-6: If a newer feature
is not
available on one of your target platform/compiler combinations you
have
to roll back to the older facility. Different compilers are at
different places toward full feature support.
Of course; but N4190 doesn't add a
The real (slight) reluctance: There is a tiny risk removing macros that
have been shipped. OTOH, if no one in their right mind would use them
then they shouldn't be out in the wild and then I say go ahead.
It might be nice to have this solidified soonish so I can maybe back out
before
A few SG10 members us were together a few minutes ago, and a suggestion was
made that we should get together this evening (during the reflection session)
to work on model text for a TS to use to introduce its feature-test macro
description(s), and that this model text should be added to SD-6.
At the meeting last night I mentioned a thought that was eluding me at the
moment. I have remembered what it was.
We should consider adding __has_include and __has_cpp_attribute to the C++17
standard. Would anyone in SG10 have any concerns about that direction?
--
Clark NelsonChair,
The library examples look good to me, I couldn't find anything to
laugh at :-)
Wow. Miracles happen sometimes.
For N4295: Folding expressions the motivating example from N4191
might be good:
#if __cpp_fold_expressions
templatetypename... T
auto sum(T... args) { return (args + ...); }
> On 3/9/2016 10:55 PM, Nelson, Clark wrote:
> >> I'd like to see a feature-test for LWG2296, "std::addressof
> should
> >> be
> >> constexpr"
> >>
> (http://wiki.edg.com/pub/Wg21jacksonville/StrawPolls/P0304R0.html).
> >
> > Woul
> >>> For example, capture of this and constexpr lambdas *could* be an
> update of __cpp_lambdas.
> >>
> >> Agreed, sounds more reasonable to me.
> >
> > That means that you can't test for support of one without the
> other, but
> > I guess that's OK.
>
> The other way to go would be to have
> On 03/10/2016 01:41 PM, John Spicer wrote:
> > I’m wondering whether some of these should be updated values of
> existing macros.
> >
> > For example, capture of this and constexpr lambdas *could* be an
> update of __cpp_lambdas.
>
> Agreed, sounds more reasonable to me.
I can see how the
> I guess the question gets back to the issue that Jason alluded to.
> To what extent, if any, does support for a later feature imply
> support for an earlier one.
Technically, supporting constexpr as in C++14 requires support for
simulating the execution of arbitrary statements, and that's hard.
> I suppose there is no hope to get people write simple code? :-)
For people who care about portability between various versions of the
standard and various real-world implementations -- probably not. :-|
Clark
___
Features mailing list
> > Finally, I proposed making the new headers from the parallelism TS
> > consistent with those from the fundamentals TS by adding macros
> (with
> > specific values) defined within those headers:
> >
> > __cpp_lib_exception_list
> > __cpp_lib_execution_policy
>
> Fine with me. (Why do we need
Here's a new draft. Significant changes:
I deleted the macros identifying all of the brand-new headers, from both
fundamentals and parallelism:
The proposal (with rationale) is now that non-const data for string
needs no macro, and similarly for enum construction rules.
I have added
The paper proposing a new overload for string::data didn't propose a
feature-test macro.
The first question is, would one be useful for it?
I'm afraid this is an area where I don't have enough experience to
trust my guesses.
Clark
___
Features mailing
> On 03/10/2016 02:30 AM, Agustín Bergé wrote:
> > For P0036, "Unary Folds and Empty Parameter Packs", maybe bump
> > `__cpp_fold_expressions`?
>
> No. If you want your code to be compatible for both C++14 and
> C++17, simply write the (previously implicit) default yourself.
> No need for an
Several of my proposals have attracted no comments so far:
__cpp_hex_float NEW
__cpp_range_based_for BUMP
__cpp_aggregate_bases NEW
searcher design mistake no macro
I also want to specifically call attention to the hardware interference
(cache-line) size
> > I think it would be perfectly reasonable to bump __cpp_constexpr
> again
> > for lambdas.
>
> Fine with me.
If anyone doesn't agree with this direction, please speak up.
> > But I'm still leaning towards having a separate macro for
> > capturing *this, at least in part for consistency
Many thanks to Richard and Jonathan for their recent suggestions.
I have posted a new draft:
http://wiki.edg.com/pub/Wg21oulu/SG10/sd-6.html#recs.cpp17
It reflects most of the recent discussion. (I am not yet assuming we have
reached consensus about any/optional.)
I have also done quite a bit
I was distracted by personal issues the week before the 15th, and I didn't
manage to put out an agenda in a timely manner. So we're trying again.
The document we'll be reviewing is posted at:
http://wiki.edg.com/pub/Wg21oulu/SG10/sd-6.html
Again, I'd kind of like people to look at everything in
Just a reminder that we're meeting in about 0.5 hours.
Clark
> -Original Message-
> From: features-boun...@open-std.org [mailto:features-bounces@open-
> std.org] On Behalf Of Nelson, Clark
> Sent: Thursday, August 25, 2016 10:53 AM
> To: featu...@open-std.org
> Subject
> This leaves ATTR_DEPRECATED undefined if the compiler doesn't
> support
> the __has_cpp_attribute macro, is that intended? Unless the idea is
> that some other method would be used to decide if it's available, it
> should be something like:
>
> #ifdef __has_cpp_attribute
> # if
I'd like to call a teleconference.
This Monday is the post-meeting mailing deadline, so that wouldn't be so good.
And then of course there will be an eclipse the morning of August 21, so that's
out.
Does anyone have any problems or preferences between August 7 and August 14?
The usual time
I'm back.
First, I'd like to apologize for my long absence. It was partly due to my
assumption that, after the CD was voted out from Oulu, we wouldn't have to
worry much about new features.
It turns out I was overly optimistic. At each of the Issaquah and Kona
meetings, we approved at least a
> The 7th is bad for me and there is a CWG conference call scheduled
> for the 14th.
>
> Some other day the week of the 21st, or maybe the 28th?
Does anyone who might be interested in attending have a problem with August 28?
Clark
___
Features mailing
Perhaps I should also ask: should the name of the macro use the word
"mandatory", or would "guaranteed" (as from the original document title) be
better?
Clark
> -Original Message-
> From: features-boun...@open-std.org [mailto:features-bounces@open-
> std.or
> After a while pondering, the best example I've got to demonstrate a
> need for the feature test macro is something like this:
>
> #ifdef __cpp_mandatory_copy_elision
>
> NoCopyNoMove indirectFactory() {
> return factory(1); // ill-formed prior to C++17
> }
> #endif
At this point I gather
> > After a while pondering, the best example I've got to
> demonstrate a
> > need for the feature test macro is something like this:
> >
> > #ifdef __cpp_mandatory_copy_elision
> >
> > NoCopyNoMove indirectFactory() {
> > return factory(1); //
02, 2017 12:58
> To: Jonathan Wakely <c...@kayari.org>
> Cc: Nelson, Clark <clark.nel...@intel.com>; featu...@isocpp.open-
> std.org <featu...@open-std.org>
> Subject: Re: [SG10] SD-6: ready for C++17?
>
> Me too.
>
> John.
>
>
> O
Unless anyone expresses an objection to this idea, I'm going to incorporate it.
I'll probably post an updated draft tomorrow.
After that I will start on updating the section references in the C++17 table.
Clark
> -Original Message-
> From: features-boun...@open-std.org
> > Should we go ahead and do that? If not, is the reason that we think
> there were no shipped implementations of the originally-defined
> interfaces for "any" and "optional"?
>
> There definitely were shipping implementations. I think we should
> update the __cp_lib_any and __cpp_lib_optional
I noticed that, although our draft says that there should be no macro for
P0032R3, we have no statement of rationale for that absence. So I looked into
the situation a little closer, to see if I could figure out the reason.
I think we were thinking that the changes to variant were being made at
, with the expectation that WG21 would
approve all subsequent revisions.
In other words, we need to explicitly consider and decide how to sequence our
goals.
Clark
> -Original Message-
> From: Nelson, Clark
> Sent: Tuesday, September 05, 2017 13:18
> To: featu...@open-std.org
> Cc: 'Vi
So it looks like the only remaining questions in the C++17 table that we
haven't considered yet are what to do about new features in the filesystem
library.
Unless someone on this list comes up with a suggestion, I'll reach out to Beman
for ideas on that.
Clark
The pre-Albuquerque mailing is only about two weeks away, so I'd better stop
sitting on this. Please see:
http://wiki.edg.com/pub/Wg21albuquerque/SG10/sd-6.html
My hope is to publish this as P0096R5 in the mailing, and then update SD-6 from
that, preferably before the meeting (assuming I hear
.@open-std.org [mailto:features-bounces@open-
> std.org] On Behalf Of Nelson, Clark
> Sent: Monday, October 09, 2017 10:41
> To: features@isocpp.open-std.org <featu...@open-std.org>
> Subject: Re: [SG10] SD-6: ready for C++17?
>
> I have posted another revision:
>
> http://w
> Furthermore, since we usually are in the business of standardizing
> things
> that users otherwise have to write many times themselves: Has SG10
> considered actively defining a header library
> that does
> the above for all the things it can, the idea being that users who
> have to
> target
43 matches
Mail list logo
