C++ Logo

sg10

Advanced search

Re: [SG10] no feature test macro for destroying delete

From: Richard Smith <richard_at_[hidden]>
Date: Thu, 14 Jun 2018 11:14:50 -0700
On 14 June 2018 at 06: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 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.


> John.
>
>
>
>
>
>
>>
>> >
>> > 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.
>>
>> John.
>> _______________________________________________
>> Features mailing list
>> Features_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/features
>>
>
>
>

Received on 2018-06-14 20:15:17