> On Jun 14, 2018, at 10:03 AM, Jonathan Wakely <[email protected]> wrote: > > > > On 14 June 2018 at 14:59, John Spicer <[email protected] <mailto:[email protected]>> > wrote: > >> On Jun 14, 2018, at 9:38 AM, Jonathan Wakely <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On 14 June 2018 at 14:31, John Spicer <[email protected] <mailto:[email protected]>> >> wrote: >> >>> On Jun 14, 2018, at 9:22 AM, Jonathan Wakely <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On 14 June 2018 at 14:08, John Spicer <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> > On Jun 13, 2018, at 9:12 PM, Richard Smith <[email protected] >>> > <mailto:[email protected]>> 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. >> > >
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
