macro BOOST_HAS_CONCEPTS not work + namespace for concepts
Hi, 1) the macro BOOST_HAS_CONCEPTS from <boost/config.hpp> (https://www.boost.org/doc/libs/1_81_0/libs/config/doc/html/boost_config/boos...) not work: https://godbolt.org/z/3G8vTrjcf 2) namespace for concepts Would it make sense to introduce a namespace *only* for concepts to avoid naming conflicts with existing classes? boost::concepts would be useful, but this is already used by the concept-check-library. Then would boost::Concepts be a good choice or could boost::concepts still be used? EG namespace boost { template <typename Type> struct my_trait ...; #if !defined(BOOST_NO_CXX17_INLINE_VARIABLES) template <typename Type> inline constexpr bool my_trait_v = my_trait<Type>::value; #endif #if concepts available namespace Concepts { template <typename Type> concept my_concept = my_trait_v<Type>; } // Concepts #endif } // boost thx Gero
On 19/02/2023 12:24, Gero Peterhoff via Boost wrote:
Hi, 1) the macro BOOST_HAS_CONCEPTS from <boost/config.hpp> (https://www.boost.org/doc/libs/1_81_0/libs/config/doc/html/boost_config/boos...) not work: https://godbolt.org/z/3G8vTrjcf
I had no idea that was there to be honest - it's hopelessly out of date and refers to previous C++ concept proposal. We need to figure out how to safely remove that. You should be using BOOST_NO_CXX20_HDR_CONCEPTS for all new code.| | HTH, John.
Hi John, Sure, you would have to fix that first to make it work at all and mark it as deprecated in the same breath. But what about my proposal for a concept-namespace? thx Gero Am 19.02.23 um 13:58 schrieb John Maddock via Boost:
On 19/02/2023 12:24, Gero Peterhoff via Boost wrote:
Hi, 1) the macro BOOST_HAS_CONCEPTS from <boost/config.hpp> (https://www.boost.org/doc/libs/1_81_0/libs/config/doc/html/boost_config/boos...) not work: https://godbolt.org/z/3G8vTrjcf
I had no idea that was there to be honest - it's hopelessly out of date and refers to previous C++ concept proposal. We need to figure out how to safely remove that.
You should be using BOOST_NO_CXX20_HDR_CONCEPTS for all new code.| |
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, Feb 19, 2023 at 05:48, Gero Peterhoff via Boost <boost@lists.boost.org> wrote:
Hi John, Sure, you would have to fix that first to make it work at all and mark it as deprecated in the same breath.
But what about my proposal for a concept-namespace?
thx Gero
Gero, John and I were actually working on something similar to your proposal a few months ago in Boost.Math https://github.com/boostorg/math/pull/848. If others find it useful we could finish it, extract it, and propose it as a boost library. Most of these concepts are domain specific right now. Matt
Hi Matt, this would be very nice. Especially with regard to the fact that many std::type-traits are not available as a concept. thx Gero Am 19.02.23 um 15:49 schrieb Matt Borland:
On Sun, Feb 19, 2023 at 05:48, Gero Peterhoff via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Hi John, Sure, you would have to fix that first to make it work at all and mark it as deprecated in the same breath.
But what about my proposal for a concept-namespace?
thx Gero
Gero,
John and I were actually working on something similar to your proposal a few months ago in Boost.Math https://github.com/boostorg/math/pull/848 <https://github.com/boostorg/math/pull/848>. If others find it useful we could finish it, extract it, and propose it as a boost library. Most of these concepts are domain specific right now.
Matt
Hi John, Sure, you would have to fix that first to make it work at all and mark it as deprecated in the same breath. Given that it's only used in two places in Boost, and only supported by an ancient experimental compiler which was never released, I'll probably just remove it from the docs. I'm not sure it had any business being
On 19/02/2023 13:48, Gero Peterhoff via Boost wrote: there in the first place.
But what about my proposal for a concept-namespace?
I have no opinion ;) Matt's suggestion for a new Concept library that extends on <concepts> is a good one, but someone else will have to write it ;) John.
Am 19.02.23 um 17:48 schrieb John Maddock via Boost:
On 19/02/2023 13:48, Gero Peterhoff via Boost wrote:
Hi John, Sure, you would have to fix that first to make it work at all and mark it as deprecated in the same breath. Given that it's only used in two places in Boost, and only supported by an ancient experimental compiler which was never released, I'll probably just remove it from the docs. I'm not sure it had any business being there in the first place.
Then do this quickly so that nobody gets the idea of actually using it.
But what about my proposal for a concept-namespace?
I have no opinion ;)
Matt's suggestion for a new Concept library that extends on <concepts> is a good one, but someone else will have to write it ;)
I'm happy to help, but I need *detailed* information about how this is planned, eg 1) Will the previous implementations of boost::concept and boost::concept_check be removed? 2) Can I use the boost::concepts namespace? 3) Could I write something like <boost/concepts.hpp> (see attachment)?
John.
thx Gero
On Sun, Feb 19, 2023 at 10:16, Gero Peterhoff via Boost <boost@lists.boost.org> wrote:
Am 19.02.23 um 17:48 schrieb John Maddock via Boost:
On 19/02/2023 13:48, Gero Peterhoff via Boost wrote:
Hi John, Sure, you would have to fix that first to make it work at all and mark it as deprecated in the same breath. Given that it's only used in two places in Boost, and only supported by an ancient experimental compiler which was never released, I'll probably just remove it from the docs. I'm not sure it had any business being there in the first place.
Then do this quickly so that nobody gets the idea of actually using it.
But what about my proposal for a concept-namespace?
I have no opinion ;)
Matt's suggestion for a new Concept library that extends on <concepts> is a good one, but someone else will have to write it ;)
I'm happy to help, but I need *detailed* information about how this is planned, eg 1) Will the previous implementations of boost::concept and boost::concept_check be removed? 2) Can I use the boost::concepts namespace? 3) Could I write something like <boost/concepts.hpp> (see attachment)?
John.
thx Gero
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gero, Are there specific concepts you are looking for? Matt
Am 20.02.23 um 00:07 schrieb Matt Borland:
On Sun, Feb 19, 2023 at 10:16, Gero Peterhoff via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Am 19.02.23 um 17:48 schrieb John Maddock via Boost:
On 19/02/2023 13:48, Gero Peterhoff via Boost wrote:
Hi John, Sure, you would have to fix that first to make it work at all and mark it as deprecated in the same breath. Given that it's only used in two places in Boost, and only supported by an ancient experimental compiler which was never released, I'll probably just remove it from the docs. I'm not sure it had any business being there in the first place.
Then do this quickly so that nobody gets the idea of actually using it.
But what about my proposal for a concept-namespace?
I have no opinion ;)
Matt's suggestion for a new Concept library that extends on <concepts> is a good one, but someone else will have to write it ;)
I'm happy to help, but I need *detailed* information about how this is planned, eg 1) Will the previous implementations of boost::concept and boost::concept_check be removed? 2) Can I use the boost::concepts namespace? 3) Could I write something like <boost/concepts.hpp> (see attachment)?
John.
thx Gero
Gero,
Are there specific concepts you are looking for?
Matt
In principle not. However, all type-traits that can be represented as a concept should also be available as a concept. And there are quite a few missing from <type_traits>/<boost/type_traits>. I mean simple things first. It gets exciting then, for example, with range-library(s). thx Gero
Are there specific concepts you are looking for?
In principle not. However, all type-traits that can be represented as a concept should also be available as a concept. And there are quite a few missing from <type_traits>/<boost/type_traits>. I mean simple things first. It gets exciting then, for example, with range-library(s).
Then I would be inclined to leave things until there's an actual demand. John.
On 2/19/23 15:24, Gero Peterhoff via Boost wrote:
Hi, 1) the macro BOOST_HAS_CONCEPTS from <boost/config.hpp> (https://www.boost.org/doc/libs/1_81_0/libs/config/doc/html/boost_config/boos...) not work: https://godbolt.org/z/3G8vTrjcf
This macro indicates support for C++0x concepts that were not accepted, not the C++20 concepts. I don't thing we have a macro for C++20 concepts.
participants (4)
-
Andrey Semashev -
Gero Peterhoff -
John Maddock -
Matt Borland