C++ Logo


Advanced search

Subject: Re: [SG10] [isocpp-lib] [isocpp-core] Missing feature-test macros
From: Richard Smith (richardsmith_at_[hidden])
Date: 2019-10-04 15:39:29

On Fri, Oct 4, 2019 at 1:29 PM Casey Carter <cartec69_at_[hidden]> wrote:

> On Fri, Oct 4, 2019 at 12:57 PM Barry Revzin via Lib <lib_at_[hidden]>
> wrote:
>> On Fri, Oct 4, 2019, 1:51 PM Richard Smith <richardsmith_at_[hidden]>
>> wrote:
>>> On Fri, Oct 4, 2019 at 6:56 AM David Vandevoorde via Lib <
>>> lib_at_[hidden]> wrote:
>>>> __cpp_lib_remove_cvref : does this need a macro? It seems like code
>>>> wishing to support old compilers could define it themselves or
>>>> unconditionally use remove_reference + remove_cv (I think this fails the
>>>> "you lose nothing by always behaving like the feature is not present" test,
>>>> unless I've overlooked a use case).
>> I wasn't sure about the traits. This one seems easily implantable (and
>> the next two), so maybe not.
> An implementation has access to tools that are not available in C++, and
> so can implement traits more efficiently than can a user. This:
> namespace stuff {
> #ifdef __cpp_lib_remove_cvref
> using std::remove_cvref_t;
> #else
> // ... implement remove_cvref_t here ...
> #endif
> }
> is more compile-time efficient on MSVC (were we to define
> __cpp_lib_remove_cvref, that is) than anything you can write for "implement
> remove_cvref_t here". Is that sufficient motivation to have feature-test
> macros even for traits that are easily implemented by hand?

Mm, good point. Personally, I find that persuasive. (It'd presumably make
even more difference, relatively-speaking, if we had
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2019/p1715r0.html and
the cost of a class template instantiation were no longer a factor.)

> For __cpp_nodiscard_reason: I'm opposed to adding this macro in isolation.
>>> Either we need to accept that version numbers for feature test macros don't
>>> work (the magic numbers are too magical) and completely rethink our
>>> approach, or we do not have adequate rationale for this.
>> Understood.
> So, we're saying that __cpp_nodiscard_reason must have a reason?
> :trollface:


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