You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm looking at adding feature detection macros to Hedley. The idea is that it would basically be a portable version of things that you're likely to test for either with __has_feature()/__has_extension() on clang or in the build system.
I'm leaning towards putting these in a second (optional) header that would be distributed alongside of hedley.h. The disadvantage there is that we wouldn't be able to use the feature test macros in hedley.h, but I think that would be acceptable since the alternative would explode the side of hedley.h.
Since autotools generally creates HAVE_* preprocessor definitions, I'm thinking HEDLEY_HAVE_* for the names.
As @travisdowns suggested on Twitter, the stuff you can use __has_feature()/__has_extension() with would be a good start, so here is a current list (based on curl -s https://clang.llvm.org/docs/LanguageExtensions.html | grep -oP '__has_(feature|extension)\([0-9a-zA-Z_]+\)' | sort | uniq)
Obviously Hedley won't support them all. The objective C ones we can safely ignore, and for the clang-specific stuff there isn't really a reason not to just use HEDLEY_HAS_FEATURE. Also, several are for testing for things Hedley already supports, like static assertions… we could probably skip those since people can just unconditionally use the Hedley versions for maximum portability.
The sanitizer ones could actually be useful since GCC defines (for example) __SANITIZE_ADDRESS__ if asan is in use instead of supporting __has_feature(address_sanitizer).
This would also be extremely useful for non-standard stuff like statement expressions which are supported by many compilers, and features from later standards that a compiler may support (e.g., using C11 generic selections in C99).
Anyways, if someone has requests for stuff not in that list, or something they would like me to prioritize, please speak up.
The text was updated successfully, but these errors were encountered:
I'm looking at adding feature detection macros to Hedley. The idea is that it would basically be a portable version of things that you're likely to test for either with
__has_feature()/__has_extension()
on clang or in the build system.I'm leaning towards putting these in a second (optional) header that would be distributed alongside of hedley.h. The disadvantage there is that we wouldn't be able to use the feature test macros in hedley.h, but I think that would be acceptable since the alternative would explode the side of hedley.h.
Since autotools generally creates
HAVE_*
preprocessor definitions, I'm thinkingHEDLEY_HAVE_*
for the names.As @travisdowns suggested on Twitter, the stuff you can use
__has_feature()/__has_extension()
with would be a good start, so here is a current list (based oncurl -s https://clang.llvm.org/docs/LanguageExtensions.html | grep -oP '__has_(feature|extension)\([0-9a-zA-Z_]+\)' | sort | uniq
)Obviously Hedley won't support them all. The objective C ones we can safely ignore, and for the clang-specific stuff there isn't really a reason not to just use
HEDLEY_HAS_FEATURE
. Also, several are for testing for things Hedley already supports, like static assertions… we could probably skip those since people can just unconditionally use the Hedley versions for maximum portability.The sanitizer ones could actually be useful since GCC defines (for example)
__SANITIZE_ADDRESS__
if asan is in use instead of supporting__has_feature(address_sanitizer)
.This would also be extremely useful for non-standard stuff like statement expressions which are supported by many compilers, and features from later standards that a compiler may support (e.g., using C11 generic selections in C99).
Anyways, if someone has requests for stuff not in that list, or something they would like me to prioritize, please speak up.
The text was updated successfully, but these errors were encountered: