Re: improve <boost/config.hpp>

From: Jeff Garland (azswdude_at_[hidden])
Date: 2023-02-27 00:22:51

My $.02. I guess my question is why we should put something in boost.config
at all.  The standard delivers the following macro for the cmath case:

#define __cpp_­lib_­constexpr_­cmath 202202L // also in <cmath>
<https://eel.is/c++draft/cmath.syn#header:%3ccmath%3e>, <cstdlib>
<https://eel.is/c++draft/cstdlib.syn#header:%3ccstdlib%3e>

https://eel.is/c++draft/version.syn

Seems like it would be better to create a library local solution that
relies directly on the standard than add macros to boost.config.  Basically
every new feature added to the standard has these macros and I think we
should always prefer using them first.

Jeff

On Fri, Feb 24, 2023 at 1:47 PM Gero Peterhoff via Boost <
boost_at_[hidden]> wrote:

> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>