[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
Marc Mutz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #9 from Marc Mutz ---
__has_include these days is defined by SD-6, and while not spelled out in
normative text, the intent is very much for it to be able to detect presence of
a header for inclusion. Quoting from
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations:
This demonstrates a way to use a library optional facility only if it is
available.
#ifdef __has_include
# if __has_include()
#include
#define have_optional 1
# elif __has_include()
#include
#define have_optional 1
#define experimental_optional
# else
#define have_optional 0
# endif
#endif
So, IMHO, you do have a bug here, because this example does not work as
intended by its defining norm.
Absent any proof to the contrary, I believe that in order to conform to SD-6,
you have to move such headers under a c++1{1,4,z}/ subdir which only gets added
to the include path if the resp. -std is in effect. This will make the example
from SD-6 work, as well as enabling the use-case Jonathan mentioned in the IRC
log.
Note that removing the #error from the header files, so they can at least be
included, if present, and a corresponding __cpp_lib macro can be evaluated is
still not conforming to SD-6, since the example assumes that availability of
the header implies usability without further checks, making __cpp_lib macros
useful for versioning
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #8 from Jonathan Wakely --- I guess another, novel, option would be a __try_include directive: #ifdef __try_include # if __try_include() // it was included without error # else // it wasn't found, or gave an error # endif #endif
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #7 from Jonathan Wakely --- (In reply to Marc Mutz from comment #1) > And no, checking __cplusplus in addition is not an option, since many > compilers, GCC included (__cplusplus==1, remember?), do not necessarily bump > __cplusplus when they implement enough core features to make something like > string_view (which can be implemented in C++11 just fine) work. I don't follow this comment. The __cplusplus==1 bug was fixed years ago (GCC 4.7.0) and since then the macro has always been bumped when a new -std option is supported. If it wasn't bumped, the #error directives that are behind this bug report wouldn't work! So while some other implementations do make available for C++11 mode, GCC is not one of them, and I don't understand the "GCC included" part of your comment. If you said that some compilers make available without -std=c++17 (or equivalent) so checking __cplusplus > 201402L would prevent using when it's actually usable, then that would be a valid argument. It's not about bumping __cplusplus or not bumping it, it's about which -std option is needed for the header to be usable. That varies between compilers, so checking "__has_include( && __cplusplus > 201402L" works, and is portable, but is overly conservative. (In reply to Marc Mutz from comment #5) > Please explain how one should detect, in a portable way, whether string_view > and experimental::string_view is available, if not by headers check. These should work portably and correctly: #ifdef __has_include #if __has_include() && __cplusplus > 201402L #ifdef __has_include #if __has_include() && __cplusplus >= 201402L As I said, they're overly conservative, but they shouldn't give false positives, only false negatives. I brought the problem up on IRC a few months ago: would it be unthinkably ugly to give #include hardcoded knowledge of standard library headers, and which -std option enables them? so that #include would automatically skip the stdinc paths if -std=c++98 ? otherwise __has_include() says yes, but including it barfs skipping the stdinc paths would allow users to provide their own fallbacks for when the standard one is not present (or rather, is present, but gets skipped) an alternative would be to put c++11 headers in a new sub-dir of $includedir/c++/$gccver/ and only add it to the include paths for -std=c++11 and up and similarly for c++14 and c++17 headers either solution is a bit smelly as discussed privately, it seems too smelly to strive for, as users can check both __cplusplus and __has_include and once the include part has been thus properly ifdeffed not to barf, the rest of the code can use a feature macro
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #6 from Eric Gallager --- (In reply to Marc Mutz from comment #5) > Andrew, you're taking the easy way out. It might be that it works as > implemented, but that behaviour is useless. > > Please explain how one should detect, in a portable way, whether string_view > and experimental::string_view is available, if not by headers check. Do an autoconf test for it, AC_CHECK_HEADERS tests whether including the header actually compiles.
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #5 from Marc Mutz --- Andrew, you're taking the easy way out. It might be that it works as implemented, but that behaviour is useless. Please explain how one should detect, in a portable way, whether string_view and experimental::string_view is available, if not by headers check.
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- .
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #3 from Andrew Pinski --- __has_include just says the include exists and not if the include file works.
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #2 from Marc Mutz --- Ok, there is __cpp_lib_experimental_string_view, at least, but it's defined ... wait for it ... in , which you can't include.
[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #1 from Marc Mutz --- And no, checking __cplusplus in addition is not an option, since many compilers, GCC included (__cplusplus==1, remember?), do not necessarily bump __cplusplus when they implement enough core features to make something like string_view (which can be implemented in C++11 just fine) work.
