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