Any chance of seeing a feature macro for HAS_IS_CONSTANT_EVALUATED appearing in Boost.Config any time soon? Robert Ramey
Robert Ramey wrote:
Any chance of seeing a feature macro for HAS_IS_CONSTANT_EVALUATED appearing in Boost.Config any time soon?
The standard feature macro for std::is_constant_evaluated is __cpp_lib_is_constant_evaluated >= 201811L (in <type_traits>). See https://en.cppreference.com/w/cpp/feature_test.
On 8/3/21 4:29 PM, Robert Ramey via Boost wrote:
Any chance of seeing a feature macro for HAS_IS_CONSTANT_EVALUATED appearing in Boost.Config any time soon?
I guess it's not really necessary as std::is_constant_evaluated is slated for C++20. And it includes a corresponding feature macro so it shouldn't be necessary for boost.config to include this functionality. I might have preferred the "unified" model of using boost.config for all these but I guess the easiest is just to role with the times.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 04/08/2021 19:05, Robert Ramey via Boost wrote:
On 8/3/21 4:29 PM, Robert Ramey via Boost wrote:
Any chance of seeing a feature macro for HAS_IS_CONSTANT_EVALUATED appearing in Boost.Config any time soon?
I guess it's not really necessary as std::is_constant_evaluated is slated for C++20. And it includes a corresponding feature macro so it shouldn't be necessary for boost.config to include this functionality. I might have preferred the "unified" model of using boost.config for all these but I guess the easiest is just to role with the times.
Actually there is a roll for Boost.Config here: std::is_constant_evaluated is valid in C++20 mode only, as is it's feature detection macro. However, the underlying compiler intrinsic works just fine all the way back to C++11 mode as long as the compiler has implemented it. Multiprecision has the logic for this already: https://github.com/boostorg/multiprecision/blob/dd4d566055ff6eee6006f8f954ef... albeit somewhat complexified because it uses __builtin_constant_p to approximate std::is_constant_evaluated on older gcc versions. John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 8/4/21 9:26 PM, John Maddock via Boost wrote:
On 04/08/2021 19:05, Robert Ramey via Boost wrote:
On 8/3/21 4:29 PM, Robert Ramey via Boost wrote:
Any chance of seeing a feature macro for HAS_IS_CONSTANT_EVALUATED appearing in Boost.Config any time soon?
I guess it's not really necessary as std::is_constant_evaluated is slated for C++20. And it includes a corresponding feature macro so it shouldn't be necessary for boost.config to include this functionality. I might have preferred the "unified" model of using boost.config for all these but I guess the easiest is just to role with the times.
Actually there is a roll for Boost.Config here: std::is_constant_evaluated is valid in C++20 mode only, as is it's feature detection macro. However, the underlying compiler intrinsic works just fine all the way back to C++11 mode as long as the compiler has implemented it.
Multiprecision has the logic for this already: https://github.com/boostorg/multiprecision/blob/dd4d566055ff6eee6006f8f954ef... albeit somewhat complexified because it uses __builtin_constant_p to approximate std::is_constant_evaluated on older gcc versions.
I might add that including <type_traits> just to test got a feature macro is not good. I think, a better solution would be a header that defines boost::is_constant_evaluated() and a BOOST_NO_IS_CONSTANT_EVALUATED macro if it is not supported and always returns false. We already have tools like this in Boost.Core.
On 5/08/2021 7:03 am, Andrey Semashev wrote:
I might add that including <type_traits> just to test got a feature macro is not good.
It wouldn't be good in something like Boost.Config, no. But if you're doing that check at actual point of use then you've almost certainly already included <type_traits> anyway, so it's "free".
On 8/5/21 2:14 AM, Gavin Lambert via Boost wrote:
On 5/08/2021 7:03 am, Andrey Semashev wrote:
I might add that including <type_traits> just to test got a feature macro is not good.
It wouldn't be good in something like Boost.Config, no.
But if you're doing that check at actual point of use then you've almost certainly already included <type_traits> anyway, so it's "free".
No, not really. Not only because needing is_constant_evaluated does not equate to needing type traits or metaprogramming, but because if the macro check says "no" then you've included <type_traits> for nothing.
On 5/08/2021 12:53 pm, Andrey Semashev wrote:
On 8/5/21 2:14 AM, Gavin Lambert wrote:
On 5/08/2021 7:03 am, Andrey Semashev wrote:
I might add that including <type_traits> just to test got a feature macro is not good.
It wouldn't be good in something like Boost.Config, no.
But if you're doing that check at actual point of use then you've almost certainly already included <type_traits> anyway, so it's "free".
No, not really. Not only because needing is_constant_evaluated does not equate to needing type traits or metaprogramming, but because if the macro check says "no" then you've included <type_traits> for nothing.
Yes, really. That's the header in which std::is_constant_evaluated is defined (as well as the feature macro you're wanting to check), so if you're wanting to use it then you have to include the header anyway. There's not really any point in making the include itself conditional (even if you could), except perhaps on something more generic (such as "is C++11 or later", to detect cases when the header wouldn't exist).
On 8/5/21 4:18 AM, Gavin Lambert via Boost wrote:
On 5/08/2021 12:53 pm, Andrey Semashev wrote:
On 8/5/21 2:14 AM, Gavin Lambert wrote:
On 5/08/2021 7:03 am, Andrey Semashev wrote:
I might add that including <type_traits> just to test got a feature macro is not good.
It wouldn't be good in something like Boost.Config, no.
But if you're doing that check at actual point of use then you've almost certainly already included <type_traits> anyway, so it's "free".
No, not really. Not only because needing is_constant_evaluated does not equate to needing type traits or metaprogramming, but because if the macro check says "no" then you've included <type_traits> for nothing.
Yes, really. That's the header in which std::is_constant_evaluated is defined (as well as the feature macro you're wanting to check), so if you're wanting to use it then you have to include the header anyway.
There's not really any point in making the include itself conditional (even if you could), except perhaps on something more generic (such as "is C++11 or later", to detect cases when the header wouldn't exist).
The point is reducing compile times. When all you need from <type_traits> is is_constant_evaluated, it is wasteful to include the header, especially if that component doesn't exist. The feature macro being defined there is a standard library design bug as it forces you to buy a car before a test drive. It was fixed by <version>, which luckily is available when is_constant_evaluated was introduced. Other feature macros were introduced before that header and their use is problematic unless you force the C++20 minimum bar. Anyway, I still think it is worth to have boost::is_constant_evaluated.
On 5/08/2021 8:09 pm, Andrey Semashev wrote:
On 8/5/21 4:18 AM, Gavin Lambert wrote:
No, not really. Not only because needing is_constant_evaluated does not equate to needing type traits or metaprogramming, but because if the macro check says "no" then you've included <type_traits> for nothing.
Yes, really. That's the header in which std::is_constant_evaluated is defined (as well as the feature macro you're wanting to check), so if you're wanting to use it then you have to include the header anyway.
There's not really any point in making the include itself conditional (even if you could), except perhaps on something more generic (such as "is C++11 or later", to detect cases when the header wouldn't exist).
The point is reducing compile times. When all you need from <type_traits> is is_constant_evaluated, it is wasteful to include the header, especially if that component doesn't exist.
The probability that any real-world translation unit does not already include <type_traits> is approximately zero. More than half the other STL headers implicitly include it anyway. (Or at least some internal equivalent.)
On 06/08/2021 1:55, Gavin Lambert via Boost wrote:
On 5/08/2021 8:09 pm, Andrey Semashev wrote:
On 8/5/21 4:18 AM, Gavin Lambert wrote:
No, not really. Not only because needing is_constant_evaluated does not equate to needing type traits or metaprogramming, but because if the macro check says "no" then you've included <type_traits> for nothing.
Yes, really. That's the header in which std::is_constant_evaluated is defined (as well as the feature macro you're wanting to check), so if you're wanting to use it then you have to include the header anyway.
There's not really any point in making the include itself conditional (even if you could), except perhaps on something more generic (such as "is C++11 or later", to detect cases when the header wouldn't exist).
The point is reducing compile times. When all you need from <type_traits> is is_constant_evaluated, it is wasteful to include the header, especially if that component doesn't exist.
The probability that any real-world translation unit does not already include <type_traits> is approximately zero. More than half the other STL headers implicitly include it anyway. (Or at least some internal equivalent.)
Except for those object files not using the STL, which are a lot if you want a decent compilation speed. Ion
On 05/08/2021 01:53, Andrey Semashev via Boost wrote:
On 8/5/21 2:14 AM, Gavin Lambert via Boost wrote:
On 5/08/2021 7:03 am, Andrey Semashev wrote:
I might add that including <type_traits> just to test got a feature macro is not good.
No need for that - we already include <version> (which is lightweight) and all that's needed in this case. Both <version> and is_constant_evaluated are C++20, so you're very unlikely to have the latter without the former. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 8/5/21 12:52 AM, John Maddock via Boost wrote:
On 05/08/2021 01:53, Andrey Semashev via Boost wrote:
On 8/5/21 2:14 AM, Gavin Lambert via Boost wrote:
On 5/08/2021 7:03 am, Andrey Semashev wrote:
I might add that including <type_traits> just to test got a feature macro is not good.
No need for that - we already include <version> (which is lightweight) and all that's needed in this case. Both <version> and is_constant_evaluated are C++20, so you're very unlikely to have the latter without the former.
OK - it's all crystal clear now ... NOT. I don't see a consensus here. I'm liking the idea of implementing boost::is_constant_evaluated() back to C++11 which a default value of false if there is not compiler support. Along with a boost config style feature macro so we'd have a unified model. Personally, I've never found compile times to be a big problem. I'm not saying that there is no compile time cost - just that it doesn't seem so much that it's been worth worrying about. Robert Ramey
On 8/4/21 11:26 AM, John Maddock via Boost wrote:
On 04/08/2021 19:05, Robert Ramey via Boost wrote:
Actually there is a roll for Boost.Config here: std::is_constant_evaluated is valid in C++20 mode only, as is it's feature detection macro. However, the underlying compiler intrinsic works just fine all the way back to C++11 mode as long as the compiler has implemented it.
Multiprecision has the logic for this already: https://github.com/boostorg/multiprecision/blob/dd4d566055ff6eee6006f8f954ef... albeit somewhat complexified because it uses __builtin_constant_p to approximate std::is_constant_evaluated on older gcc versions.
This looks what I w was looking for. Is there any chance to get this moved into Boost.Config ? I think it would be even better than what I was looking for. Robert Ramey
John.
On 07/08/2021 05:46, Robert Ramey via Boost wrote:
On 8/4/21 11:26 AM, John Maddock via Boost wrote:
On 04/08/2021 19:05, Robert Ramey via Boost wrote:
Actually there is a roll for Boost.Config here: std::is_constant_evaluated is valid in C++20 mode only, as is it's feature detection macro. However, the underlying compiler intrinsic works just fine all the way back to C++11 mode as long as the compiler has implemented it.
Multiprecision has the logic for this already: https://github.com/boostorg/multiprecision/blob/dd4d566055ff6eee6006f8f954ef... albeit somewhat complexified because it uses __builtin_constant_p to approximate std::is_constant_evaluated on older gcc versions.
This looks what I w was looking for. Is there any chance to get this moved into Boost.Config ? I think it would be even better than what I was looking for.
Yes, just give me a few days I'm tied up right now, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 8/7/21 12:13 AM, John Maddock via Boost wrote:
On 07/08/2021 05:46, Robert Ramey via Boost wrote:
This looks what I w was looking for. Is there any chance to get this moved into Boost.Config ? I think it would be even better than what I was looking for.
Yes, just give me a few days I'm tied up right now, John.
Not super urgent. I'm bogged down also. As an aside, let me state that that John Maddock (along with another select few) is one of the most under appreciated persons in Boost, and indeed C++. Robert Ramey
On 08/08/2021 16:31, Michael Caisse via Boost wrote:
On 8/7/21 08:37, Robert Ramey via Boost wrote:
As an aside, let me state that that John Maddock (along with another select few) is one of the most under appreciated persons in Boost, and indeed C++.
Robert Ramey I completely agree!
Thank you gentlemen. In the mean time, if you would all like to revert to your more critical selves ;) here's the docs for the proposed addition to Boost.Config: https://github.com/boostorg/config/pull/394/files#diff-44c14c3d1351a80ad9f4a... Note the full PR has failures, which I'll look into later. Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 8/8/21 11:32 AM, John Maddock via Boost wrote:
On 08/08/2021 16:31, Michael Caisse via Boost wrote:
On 8/7/21 08:37, Robert Ramey via Boost wrote:
As an aside, let me state that that John Maddock (along with another select few) is one of the most under appreciated persons in Boost, and indeed C++.
Robert Ramey I completely agree!
Thank you gentlemen.
In the mean time, if you would all like to revert to your more critical selves ;) here's the docs for the proposed addition to Boost.Config: https://github.com/boostorg/config/pull/394/files#diff-44c14c3d1351a80ad9f4a...
Note the full PR has failures, which I'll look into later.
Best, John.
I've looked at this and have a couple of questions: a) I see BOOST_NO_CXX20_IS_CONSTANT_EVALUATED and presume that's it's like all the other boost feature macros. So far so good. This might return true or false independently of the C++ version being used. That is, I could be compiling with C++14 and the macro might return true. This might direct the generation of the most optimal code but that that code might be different depending on the compiler being tested. I'm concerned about being able to test for portability/standards conformance. So I'd like to be able to have BOOST_NO_CXX20_IS_CONSTANT_EVALUATED defined either in accordance with the standard version or with the actual compiler capability. So I'd run my tests twice: 1) with the most efficient implementation. 2) with the standards conforming implementation. Assuming it passes 2) (al be it more slowly) I would know that my test/application could always be counted on to pass. I don't know if I explained myself well. Robert Ramey
I've looked at this and have a couple of questions:
a) I see BOOST_NO_CXX20_IS_CONSTANT_EVALUATED and presume that's it's like all the other boost feature macros. So far so good.
This might return true or false independently of the C++ version being used. That is, I could be compiling with C++14 and the macro might return true. This might direct the generation of the most optimal code but that that code might be different depending on the compiler being tested. I'm concerned about being able to test for portability/standards conformance. So I'd like to be able to have BOOST_NO_CXX20_IS_CONSTANT_EVALUATED defined either in accordance with the standard version or with the actual compiler capability. So I'd run my tests twice:
1) with the most efficient implementation. 2) with the standards conforming implementation.
Assuming it passes 2) (al be it more slowly) I would know that my test/application could always be counted on to pass.
I don't know if I explained myself well.
Not really ;) BOOST_NO_CXX20_IS_CONSTANT_EVALUATED is defined if there is no std::is_constant_evaluated() in type_traits: for all current compilers/std libs that means real C++20 mode as well as compiler intrinsic support. In contrast BOOST_IS_CONSTANT_EVALUATED() works in C++14/17 etc if the required intrinsic is present. John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Don't want to offtopic too much, but does anybody else feels that we could use runtime_assert in boost? Name might be dumb(alternatives: runeval_assert, smart_assert, ...), but idea is to fix the issue of assert messing with constexpr functions by running assert only at runtime. Does something like this already exists in Boost? https://www.godbolt.org/z/nTzh6TfKK (uses C++23 if consteval, but obviously it can be made to work in C++20). Unfortunately error text is useless for most developers since it dies in runtime_assert, but probably better than nothing. Also maybe somebody knows a portable Boost way to get the nicer error message to users, maybe using std::source_location? On Sat, Aug 7, 2021 at 9:14 AM John Maddock via Boost <boost@lists.boost.org> wrote:
Yes, just give me a few days I'm tied up right now, John.
participants (8)
-
Andrey Semashev -
Gavin Lambert -
Ion Gaztañaga -
Ivan Matek -
John Maddock -
Michael Caisse -
Peter Dimov -
Robert Ramey