improve <boost/config.hpp>
Hi, for more compatibility with existing boost-macros/defines I came up with - see attachment. 1) Is that correct in principle? 2) Problem: for BOOST_NO_CXX23_HDR_XXX I use __has_include. However, __has_include is not guaranteed to exist. How about the solution? 3) Did I miss useful things? thx Gero
On 2/20/23 01: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? 2) Problem: for BOOST_NO_CXX23_HDR_XXX I use __has_include. However, __has_include is not guaranteed to exist. How about the solution? 3) Did I miss useful things?
Just a bystander's 2 cents. 1. No tabs, please. 2. Re. BOOST_INLINE_STATIC_CONSTEXPR. There is already BOOST_INLINE_VARIABLE that you can combine with BOOST_CONSTEXPR_OR_CONST, no need for a yet another macro. BTW, we also have BOOST_NO_CXX17_INLINE_VARIABLES. 3. Re. BOOST_NO_CXX20 and BOOST_NO_CXX20. No need for those, just use BOOST_CXX_VERSION directly. Note that some compilers use non-standard values for __cplusplus (and consequently BOOST_CXX_VERSION). 4. Re. BOOST_CXX17_CONSTEXPR, BOOST_CXX20_CONSTEXPR, etc. Are there many significant improvements to constexpr in C++17 and so on to warrant a new macro? Specifically, improvements that are useful to Boost libraries. 5. You should generally place compiler and library feature macros in compiler- and library-specific headers, not in one header. 6. You should also add tests for each feature macro. Testing for __has_include and compiler-defined macros is not enough - you should ensure the compiler actually properly supports the advertised feature. 7. If you're testing compiler-defined feature macros, like __cpp_consteval, you should also test for its value, not just that it's defined. 8. Not all compilers define feature macros, even if they do support the features. Boost.Config should check the compiler version and/or the current C++ mode to know what it supports. This should be implemented in the compiler-specific header.
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? BTW we generally only add new macros at the request of an existing boost library.
2) Problem: for BOOST_NO_CXX23_HDR_XXX I use __has_include. However, __has_include is not guaranteed to exist. How about the solution?
We deal with this like this: https://github.com/boostorg/config/blob/ab271393a7f9321d34ca641cc2b042aa0817... It's not trivial, and I would like to have a (released) C++23 compiler to test with before committing to this. John.
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
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@lists.boost.org> wrote:
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
Am 20.02.23 um 14:11 schrieb John Maddock via Boost: 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
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. 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. I hope that helps, Alex
On 20. Feb 2023, at 14:11, John Maddock via Boost <boost@lists.boost.org> wrote:
BTW we generally only add new macros at the request of an existing boost library.
Another bystander comment: I think Boost.Config is very useful also for external libs that want to work around compiler / library bugs, so I would be in favour to consider feature requests from non-boost authors. It is probably quite difficult even today to write a truly platform-independent lib without Boost.Config.
participants (6)
-
Alexander Grund -
Andrey Semashev -
Gero Peterhoff -
Hans Dembinski -
Jeff Garland -
John Maddock