C++ Logo

SG10

Advanced search

Subject: Re: [SG10] Comments from Alisdair
From: Ed Smith-Rowland (3dw4rd_at_[hidden])
Date: 2014-05-22 22:51:22


On 05/22/2014 07:58 PM, Nelson, Clark wrote:
> OK, I have added entries for all of the library issues mentioned by
> Alisdair. No macro for gets, but macros for the other three. For two of
> them, no one gave any feedback, but I went ahead and filled in the obvious
> values. They are all marked by editorial question marks.
>
> Besides a few tweaks, those are the only changes since I posted it on April
> Fool's Day. I plan to put the result (attached) into the mailing as N4030,
> mainly so we can get more eyes on the __has_cpp_attribute feature.
>
> Clark
>
>
> From: metafoo_at_[hidden] [mailto:metafoo_at_[hidden]] On Behalf Of Richard Smith
> Sent: Thursday, May 15, 2014 4:19 PM
> To: Nelson, Clark
> Cc: features_at_[hidden] (features_at_[hidden])
> Subject: Re: [SG10] Comments from Alisdair
>
> On Thu, May 15, 2014 at 4:13 PM, Nelson, Clark <clark.nelson_at_[hidden]> wrote:
> I got a few comments today about SD-6 from Alisdair Meredith. Most of them
> were just pointing out that it needs to be updated, which we already knew,
> and which is in progress. But there are a few I thought I should pass along.
>
>> We added an 'is_final' type-trait at the last meeting too, not
>> sure what name to recommend (issue 2112) and 'is_null_pointer' at
>> Chicago (issue 2247)
>>
>> We added 'make_reverse_iterator' to the <iterator> header (issue
>> 2285)
> It came as news to me that we, as a committee, have added features to the
> standard in response to issues (a.k.a. defect reports). Obviously, those of
> us who feel that's a bad idea in general might want to suggest that we be
> more careful to avoid that in the future. :-(
>
> But apparently we have some water under the bridge, and SG10 needs to decide
> whether these should have macros.
>
> I think an is_final feature-detection macro makes a lot of sense. Libraries that want to do EBO could reasonably want to use is_final && is_empty if is_final exists, and fall back to just using is_empty otherwise.
>
>> Finally, do we want a feature to detect that 'gets' has finally
>> been removed? (NB comment GB 9 in N3733)
> I'm not even going to try to frame this question. :-/ (This is library issue
> 2249, for anyone who wants more information.)
>
> I don't see any value in a macro for gets. Code that doesn't use gets doesn't need the macro, and code that uses it is neither portable to C++14 nor correct :-)
>
>> Oh, and as a point of curiosity, it turned out that there is no
>> feature-detect macro for the C++11 feature I am trying to detect,
>> alias templates! I am surprised at just how useful I am finding
>> this feature at the moment, but mostly as a porting aid, saying
>> "this old code is now implemented using that new more
>> general/standard feature over there" (plus implementing the few
>> places that standard library mandates them).
> Is there anyone who thinks that this would not be a good idea? (This was
> adopted from N2258.)
>
> SGTM. __cpp_alias_templates?
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
Do we want in the examples
__has_include(<optional>), etc.
or
__has_include(<experimental/optional>), etc.

I thought the experimental headers aren't in with the std headers.

Or do I have that wrong?



SG10 list run by sg10-owner@lists.isocpp.org