Am 20.02.23 um 14:11 schrieb John Maddock via Boost:
On 19/02/2023 22: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?
These are best dealt with via PR's on Github - preferable one macro at a time and with test cases.
See https://www.boost.org/doc/libs/1_81_0/libs/config/doc/html/boost_config/guid...
For BOOST_CXXNN_CONSTEXPR: yes there are constexpr updates for each of the last few standards, but I'm having a hard time seeing what the benefit of these macros are over checking __cpp_constexpr directly?
This prevents redundant and error-prone #if-#else constructions. For example, std::round in C++23 (https://en.cppreference.com/w/cpp/numeric/math/round) is constexpr. If I now write a function template <typename Type> inline BOOST_CXX23_CONSTEXPR Type round_even(const Type x) noexcept { static_assert(std::is_arithmetic<Type>::value, "invalid type"); BOOST_IF_CONSTEXPR (std::is_floating_point<Type>::value) return std::round(x * Type(0.5)) * 2; else return x; } this is unambiguous and readable. But I don't understand why you are against it. After all, there is BOOST_CXX14_CONSTEXPR (BOOST_CXX17/20_CONSTEXPR are still missing - but I already offered that). So we have an expressive scheme BOOST_CXXnn_CONSTEXPR that is unambiguous and readable. thx Gero