Re: improve <boost/config.hpp>

From: Gero Peterhoff (g.peterhoff_at_[hidden])
Date: 2023-02-24 20:47:18

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/guidelines_for_boost_authors.html#boost_config.guidelines_for_boost_authors.adding_new_defect_macros

> 
> 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