> On Feb 9, 2017, at 6:55 PM, Jonathan Wakely <[email protected]> wrote: > > On 9 February 2017 at 23:25, Jens Maurer <[email protected]> wrote: >> On 02/09/2017 11:59 PM, Jonathan Wakely wrote: >>> It's become apparent that the feature-test recommendations for >>> features such as std::string_view, std::variant and std::optional are >>> not sufficient. >>> >>> SD-6 says that to check for std::variant you should use >>> __has_include(<variant>). >> >> My gut reaction to this issue is >> "can't we make __has_include return false if #including >> the header doesn't actually provide the facility"? > > Do you mean some way for a header to inform the preprocessor that > although it exists as a file on disk, it should be ignored? That might > be nice, although non-trivial to implement. The preprocessor might > have to open the file, do some basic preprocessing (so that macros > such as __cplusplus and __linux__ and __x86_64__ can be tested in > preprocessor conditions) and check what happens. Either an #error or > some implementation-defined #pragma could make __has_include return > false. That would be a significant change to __has_include, which > currently doesn't need to open the file. > > Maybe compilers could deal with it in non-standard ways, so that if > the first line of the header contains some #pragma the __has_include > is false (so the whole file doesn't need to be preprocessed) For > example: > > #pragma GCC has_include(__cplusplus >= 201402L) > > That could cause __has_include to return the result of the expression > (converted to either 0 or 1, in case somebody uses an expression that > has some other non-zero value). > > I originally thought about a __try_include feature, that would attempt > to include the header and if either evaluate to 1 on success, or 0 if > there was an error (either finding the header, or processing it). That > could also be non-trivial to implement though, if for example the > header does: > > #define SOME_MACRO 1 > #error "blah blah" > > Would the macro remain defined after an unsuccessful __try_include ? > > If not it might be unpopular with preprocessor implementors. If yes > ... it's nasty, but maybe we could say it's unspecified whether any > macros get defined by a failed __try_include. That seems really nasty > though. The error could be in a header included indirectly, after > several other files have been included and liberally defined their own > macros. > > >> (I would also be happy if "#include <variant>" would simply >> be an error in older modes, although I do agree the gcc >> error message is helpful.) > > I thought about proposing a change to the GCC compiler that would > hardcode the __has_include result for standard header names, so it > would be false in C++14 mode, but that might prevent users from > supplying their own <variant> that works in C++14 (technically it's > undefined to give an include file the same name as a standard header, > but in C++14 <variant> isn't a standard header, so it's OK for users > to use). > > Adding extra __cpp_lib_xxx macros to SD-6 seemed the simplest > approach, and requires the least work from implementors.
This seems like the best approach to me. John. > > But if people would rather I try to solve this in libstdc++ I can talk > to the GCC folks about the #pragma idea, or something like that (and > then hope that Intel and Clang and others to support it too). > _______________________________________________ > 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
