On 14 June 2018 at 06:31, John Spicer <j...@edg.com> wrote: > > On Jun 14, 2018, at 9:22 AM, Jonathan Wakely <c...@kayari.org> wrote: > > > > On 14 June 2018 at 14:08, John Spicer <j...@edg.com> wrote: > >> >> > On Jun 13, 2018, at 9:12 PM, Richard Smith <rich...@metafoo.co.uk> >> 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@isocpp.open-std.org >> http://www.open-std.org/mailman/listinfo/features >> > > >
_______________________________________________ Features mailing list Features@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/features
