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