> On Jun 14, 2018, at 9:38 AM, Jonathan Wakely <[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. 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
