C++ Logo


Advanced search

Re: [SG10] [isocpp-lib] [isocpp-core] Missing feature-test macros

From: Casey Carter <cartec69_at_[hidden]>
Date: Fri, 4 Oct 2019 13:29:04 -0700
On Fri, Oct 4, 2019 at 12:57 PM Barry Revzin via Lib <lib_at_[hidden]>

> 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;
// ... implement remove_cvref_t here ...

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?

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?

Received on 2019-10-04 22:29:19