> On Jun 14, 2018, at 10:03 AM, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> On 14 June 2018 at 14:59, John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]>> wrote:
>
>> On Jun 14, 2018, at 9:38 AM, Jonathan Wakely <cxx_at_[hidden] <mailto:cxx_at_[hidden]>> wrote:
>>
>>
>>
>> On 14 June 2018 at 14:31, John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]>> wrote:
>>
>>> On Jun 14, 2018, at 9:22 AM, Jonathan Wakely <cxx_at_[hidden] <mailto:cxx_at_[hidden]>> wrote:
>>>
>>>
>>>
>>> On 14 June 2018 at 14:08, John Spicer <jhs_at_[hidden] <mailto:jhs_at_[hidden]>> wrote:
>>>
>>> > On Jun 13, 2018, at 9:12 PM, Richard Smith <richard_at_[hidden] <mailto:richard_at_[hidden]>> 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 compiler could set its macro, and the library conditionally define the library functions and library macro only if the compiler macro is defined. The user would check the library macro.
>>
>> That does mean we'd have a compiler macro that users are never meant to use, because it doesn't tell you anything useful in isolation.
>
> That wouldn’t work if the user was using a compiler that didn’t have the feature but the library was built with one that did have the feature.
>
> Isn't it just the declaration of the functions in <new> that the library needs to suppress when the compiler can't support them?
>
> The library could be built with a different compiler and still contain definitions for those functions, but as long as it doesn't expose them in the header during preprocessing the user can't call them.

Yes, if the library tested the compiler flag, that would work.

John.

>
>
>
> The user would have to test both the language flag *and* the library flag.
>
> John.
>
>>
>>
>>
>> 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.
>>
>> I agree the general case can't be solved by feature test macros, but maybe this one can.
>>
>
>