From: Jeff Garland (azswdude_at_[hidden])
Date: 2023-03-07 15:22:03
On Fri, Mar 3, 2023 at 8:04 AM Alexander Grund via Boost <
boost_at_[hidden]> wrote:
>
> > 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.
>
> C++14 lifted some major constraints on what can be in a constexpr
> function compared to C++11. Most notably support for more than just a
> return statement. Being able to differentiate that is useful in practice.
>
> > For example, std::round in C++23 is constexpr
>
> The CXXyy part in the Boost.Config macros refers to the language level
> support. While std::round is at library level. So a compiler supporting
> C++14 constexpr syntax might not have a std library where std::round is
> constexpr even if it claims C++23 support. So the better way here would
> be a more focused macro combining the language level of the constexpr
> feature and the library support of what that specific function is using.
>
> Hence a possible BOOST_CXX23_CONSTEXPR is misleading: It doesn't refer
> to the language level anymore. And if you bind that to availability of
> constexpr std::round the next user may want to use it with another std::
> function which is supposed to be constexpr in C++23 but due to a std
> library defect is not yet. Hence the distinction between library level
> and language level feature macros.
>
Please see: https://en.cppreference.com/w/cpp/feature_test for language
level macros -- look for _cpp_constexpr. I believe you'll discover that
every combination you're looking for going back to cxx 2011 is represented
-- basically making a boost config macro extraneous. The standard copied
this idea from boost.config btw and it's quite powerful for portable
libraries. Note that I regret using the boost.config macro for date-time
constexpr stuff, because at this point I'd like to make the library
available in a stand-alone fashion like boost.math. Not depending on
boost.config would be helpful in that endeavor.
> However IIRC some C++ standard added support of (temporary) allocations
> in constexpr functions. That would be worth a dedicated feature macro as
> that change fits the idea described above.
>
w.r.t. non-standard allocation support, sure that would be an extension
perhaps worthy of a boost macro, but also maybe just check the compiler
locally in the library that wants to use that extension.
Jeff