On 2/20/23 01:27, Gero Peterhoff via Boost wrote:
Hi, for more compatibility with existing boost-macros/defines I came up with - see attachment. 1) Is that correct in principle? 2) Problem: for BOOST_NO_CXX23_HDR_XXX I use __has_include. However, __has_include is not guaranteed to exist. How about the solution? 3) Did I miss useful things?
Just a bystander's 2 cents. 1. No tabs, please. 2. Re. BOOST_INLINE_STATIC_CONSTEXPR. There is already BOOST_INLINE_VARIABLE that you can combine with BOOST_CONSTEXPR_OR_CONST, no need for a yet another macro. BTW, we also have BOOST_NO_CXX17_INLINE_VARIABLES. 3. Re. BOOST_NO_CXX20 and BOOST_NO_CXX20. No need for those, just use BOOST_CXX_VERSION directly. Note that some compilers use non-standard values for __cplusplus (and consequently BOOST_CXX_VERSION). 4. Re. BOOST_CXX17_CONSTEXPR, BOOST_CXX20_CONSTEXPR, etc. Are there many significant improvements to constexpr in C++17 and so on to warrant a new macro? Specifically, improvements that are useful to Boost libraries. 5. You should generally place compiler and library feature macros in compiler- and library-specific headers, not in one header. 6. You should also add tests for each feature macro. Testing for __has_include and compiler-defined macros is not enough - you should ensure the compiler actually properly supports the advertised feature. 7. If you're testing compiler-defined feature macros, like __cpp_consteval, you should also test for its value, not just that it's defined. 8. Not all compilers define feature macros, even if they do support the features. Boost.Config should check the compiler version and/or the current C++ mode to know what it supports. This should be implemented in the compiler-specific header.