C++ Logo


Advanced search

Subject: Re: [SG10] Comments from Alisdair
From: Richard Smith (richard_at_[hidden])
Date: 2014-05-22 19:25:21

The __cpp_lib_has_$foo macros seem to be using a different naming
convention from our previous macros, where we had just __cpp_lib_$foo. Is
this a deliberate change of direction?

On Thu, May 22, 2014 at 4:58 PM, Nelson, Clark <clark.nelson_at_[hidden]>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

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