For example, -Wimplicit-const-int-float-conversion was added in clang 11, so if _has_warning("-Wimplicit-const-int-float-conversion") is true we can assume the upstream clang version is >= 11. My work-around is to use feature detection macros to estimate a version number. For me, the fatal flaw is that it doesn't really work for compilers other than Apple clang there are a lot of compilers based on clang these days (IBM XL C/C++, some newer PGI/NVIDIA compilers, next-gen Intel C/C++, etc.). You could manually create a map of Apple version numbers to upstream, which is what several other answers have proposed, but that has some pretty obvious drawbacks. I really wish clang would just expose the upstream version numbers as preprocessor macros so we could reliably handle cases like that, but they don't. Sometimes a feature is added but there is no corresponding check. Sometimes new functionality is added for example, prior to clang 9 _builtin_constant_p didn't work correctly with the diagnose_if attribute. For example, sometimes it is necessary to work around compiler bugs which have been fixed in newer versions, or which only appear in newer versions. That said, sometimes you really do need to check the version. The Clang Language Extensions page documents the different things you can check for, and that should be your go-to solution.
First, I want to say that Daniel Frey's answer is absolutely correct you really should be using _has_feature, _has_extension, etc.
0 kommentar(er)
