On 14 June 2018 at 14:59, John Spicer <jhs_at_[hidden]> wrote:

>
> On Jun 14, 2018, at 9:38 AM, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> On 14 June 2018 at 14:31, John Spicer <jhs_at_[hidden]> wrote:
>
>>
>> On Jun 14, 2018, at 9:22 AM, Jonathan Wakely <cxx_at_[hidden]> wrote:
>>
>>
>>
>> On 14 June 2018 at 14:08, John Spicer <jhs_at_[hidden]> wrote:
>>
>>>
>>> > On Jun 13, 2018, at 9:12 PM, Richard Smith <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.



>
> 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.
>
>
>