Re: improve <boost/config.hpp>

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-03-07 15:38:06

On 3/7/23 18:22, Jeff Garland via Boost wrote:
> 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.

Not every compiler defines these macros. Let alone, not every compiler
properly implements what it advertises.

Also, library-defined macros are worthless as they only allow one to
know the feature is/isn't supported after including the header, i.e.
after the fact. C++20 <version> fixes this, but C++20 is a too high
minimum bar to target.

So no, feature macros do not replace Boost.Config. In fact, I'd prefer
to continue using Boost.Config in new libraries.