On 14 June 2018 at 06:31, John Spicer <jhs@edg.com> wrote:

On Jun 14, 2018, at 9:22 AM, Jonathan Wakely <cxx@kayari.org> wrote:

On 14 June 2018 at 14:08, John Spicer <jhs@edg.com> wrote:

> On Jun 13, 2018, at 9:12 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> P0722R3 (wg21.link/p0722r3, just voted into the standard) does not specify a feature test macro, but I think it would benefit from one. However, it's not completely clear how we should arrange this: it needs both compiler support and library support, and is unusable without both.
> Should we add two feature test macros for it (one for compiler, one for library)? Should we recommend that the library macro be defined only if the language macro is defined, so that users need only check one, or should we keep them separate, to allow the library functionality to be discovered despite the language functionality being absent? (In the latter case, a library could be built using an old compiler and a new library, and provide functionality to clients that are built using a new compiler and a new library.)

I think the normal case is that the compiler and library will be supplied together, so that only the language macro should be needed.

It's common for Clang and ICC to be used with Libstdc++, in which case we need both macros. The compiler might support the feature and define the macro, but unless a sufficiently-new version of Libstdc++ is used the library won't support it.


In the case where you are using a library from somewhere else, and the library does not include the feature, I think the language feature would need to be disabled in the compiler (e.g., by a command-line option) and that would turn off the language macro.

That requires knowing a priori which version of the std::lib you're using and which features that version supports. That's one of the annoyances feature test macros are supposed to remove :-)

So, is the implementation supposed to test the library flag to decide how to set its flag?

The compatibility of a compiler and a library does not seem like it can, in general, be solved by feature test macros.

As an example, an implementation can generate a call to the aligned operator new without the <new> header ever being included, but it will fail to link if the library doesn’t include the function.

The situation with aligned new (and likewise sized delete) is a major headache that we don't have a good solution for, not something that I'd like to use as a model for future features. We tried sniffing the environment to guess whether support for aligned new / sized delete is available, and we failed to make that work, so I do not want that to be part of the feature test macro model.

I think two macros makes most sense, but I'm less sure whether we want two independent macros or a library macro that's only defined if the compiler macro is defined.

There's at least one other feature for which we currently lack a feature test macro but has the same problem: three-way comparison.


> Where should such discussions occur these days (now that the feature test macros have been merged into the standard)? I'm assuming this is still the right place.

I’m not sure, but I think maybe these should start being discussed on the other reflectors.

I think we want to continue maintaining sd-6, and things related to that should be discussed here.

Features mailing list