Re: improve <boost/config.hpp>

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-02-19 22:56:31

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.