Hi, Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example? Thanks, Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
If nobody else responds otherwise, I'm going to say "no" based on my last look at the library. For the time being, you're stuck using traits classes to accomplish concept specialization. Of course, things change so I could be completely wrong. It wouldn't be the first time :) Andrew Sutton asutton@cs.kent.edu
Anthony Williams-3 wrote:
Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
See http://www.nabble.com/forum/ViewPost.jtp?post=15220025&framed=y It seems that until we get C++0x we can't statically dispatch on all concepts. Best Regards, Johan -- View this message in context: http://www.nabble.com/Overloading-on-concepts-tp17104187p17109944.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Johan Torp <johan.torp@gmail.com> writes:
Anthony Williams-3 wrote:
Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
See http://www.nabble.com/forum/ViewPost.jtp?post=15220025&framed=y
It seems that until we get C++0x we can't statically dispatch on all concepts.
Thanks, I thought as much. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
From: "Anthony Williams" <anthony_w.geo@yahoo.com>
Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
As someone was pointed out in another posting, you can't use BCCL for this, since the checks fail with a compile error if a concept doesn't match. However, if you're able to define compile-time traits performing the concept check, then you _can_ overload on concepts, using enable_if. See the Concept Traits Library (http://web.archive.org/web/20050428001254/http://neoscientists.org/~tschwin ger/boostdev/concept_traits/libs/concept_traits/doc/) for an approach to this. This library is no longer maintained (at least by me, and unfortunately I don't have the source available right now, but Tobias Schwinger may have it around somewhere), not at least due to the upcoming C++0x, where this is supported in the language. The above library was mostly an experiment about how to get support for concepts in a library solution, but you really need language support to get the full effect of concepts. Regards, Terje
On Wed, May 7, 2008 at 2:15 PM, Terje Slettebø <tslettebo@broadpark.no> wrote:
From: "Anthony Williams" <anthony_w.geo@yahoo.com>
Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
As someone was pointed out in another posting, you can't use BCCL for this, since the checks fail with a compile error if a concept doesn't match. However, if you're able to define compile-time traits performing the concept check, then you _can_ overload on concepts, using enable_if. See the Concept Traits Library (http://web.archive.org/web/20050428001254/http://neoscientists.org/~tschwin ger/boostdev/concept_traits/libs/concept_traits/doc/) for an approach to this.
This library is no longer maintained (at least by me, and unfortunately I don't have the source available right now, but Tobias Schwinger may have it around somewhere), not at least due to the upcoming C++0x, where this is supported in the language.
The above library was mostly an experiment about how to get support for concepts in a library solution, but you really need language support to get the full effect of concepts.
That looks extremely interesting. I needed this a few months ago, and was disappointed when I discovered that you couldn't do this with BCCL. I would love if this was made available somehow. --Michael Fawcett
Hi Michael. Thanks for your kind remarks. (Having been away from the C++ community a few years, I get reminded of how great it is.) I've put the library here: http://home.broadpark.no/~terjesl/files/concept_traits_original.zip http://home.broadpark.no/~terjesl/files/concept_traits.zip The first one is the original version. Tobias Schwinger has done a lot of work with the library, speeding up the compilation a lot. However, I don't know how finished it is, but the second link above is the latest version I have of the new version, although Tobias may have a newer one. Nevertheless, the first one has been tested, it has the same interface as the new version, and it might be easier to understand (as it uses Boost.MPL for the metaprogramming), so it might be best to start experimenting with that one. The library includes documentation, examples and unit tests. It's not a Boost library, but it uses the same directory structure and naming conventions as Boost, allowing it to work well together with Boost (and it depends on a few Boost libraries, as well, such as Boost.MPL and Type Traits). The library includes traits for all the documented concepts in the C++ standard, as well as the MPL concepts. Feel free to contact me off list if you have any questions or comments about it. Regards, Terje ----- Original Message ----- From: "Michael Fawcett" <michael.fawcett@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, May 07, 2008 10:48 PM Subject: Re: [boost] Overloading on concepts On Wed, May 7, 2008 at 2:15 PM, Terje Slettebø <tslettebo@broadpark.no> wrote:
From: "Anthony Williams" <anthony_w.geo@yahoo.com>
Does the boost concept checking library support overloading on concepts, so and you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
As someone was pointed out in another posting, you can't use BCCL for this, since the checks fail with a compile error if a concept doesn't match. However, if you're able to define compile-time traits performing the concept check, then you _can_ overload on concepts, using enable_if. See the Concept Traits Library
(http://web.archive.org/web/20050428001254/http://neoscientists.org/~tschwin
ger/boostdev/concept_traits/libs/concept_traits/doc/) for an approach to this.
This library is no longer maintained (at least by me, and unfortunately I don't have the source available right now, but Tobias Schwinger may have it around somewhere), not at least due to the upcoming C++0x, where this is supported in the language.
The above library was mostly an experiment about how to get support for concepts in a library solution, but you really need language support to get the full effect of concepts.
That looks extremely interesting. I needed this a few months ago, and was disappointed when I discovered that you couldn't do this with BCCL. I would love if this was made available somehow. --Michael Fawcett _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Terje Slettebø <tslettebo@broadpark.no> writes:
From: "Anthony Williams" <anthony_w.geo@yahoo.com>
Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
As someone was pointed out in another posting, you can't use BCCL for this, since the checks fail with a compile error if a concept doesn't match. However, if you're able to define compile-time traits performing the concept check, then you _can_ overload on concepts, using enable_if. See the Concept Traits Library (http://web.archive.org/web/20050428001254/http://neoscientists.org/~tschwin ger/boostdev/concept_traits/libs/concept_traits/doc/) for an approach to this.
Thanks. That's essentially what I was trying to do. I'll see if there's anything in there I can use. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Terje Slettebø wrote:
From: "Anthony Williams" <anthony_w.geo@yahoo.com> Does the boost concept checking library support overloading on concepts, so you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
As someone was pointed out in another posting, you can't use BCCL for this, since the checks fail with a compile error if a concept doesn't match. However, if you're able to define compile-time traits performing the concept check, then you _can_ overload on concepts, using enable_if. See the Concept Traits Library (http://web.archive.org/web/20050428001254/http://neoscientists.org/~tschwin ger/boostdev/concept_traits/libs/concept_traits/doc/) for an approach to this.
This library is no longer maintained (at least by me, and unfortunately I don't have the source available right now, but Tobias Schwinger may have it around somewhere), not at least due to the upcoming C++0x, where this is supported in the language.
The above library was mostly an experiment about how to get support for concepts in a library solution, but you really need language support to get the full effect of concepts.
That's really interesting and exactly what I was looking for a while back! According to David Abrahams (http://www.nabble.com/forum/ViewPost.jtp?post=15220025&framed=y) you can't implement all requirements of all concepts as traits though. Did you bump into this? What kind of requirements can't be implemented as traits? I'll have a look at your library later on today. Best Regards, Johan -- View this message in context: http://www.nabble.com/Overloading-on-concepts-tp17104187p17122251.html Sent from the Boost - Dev mailing list archive at Nabble.com.
HiJohan.
From: "Johan Torp" <johan.torp@gmail.com>
Terje Slettebø wrote:
From: "Anthony Williams" <anthony_w.geo@yahoo.com> Does the boost concept checking library support overloading on
concepts,
so
you can have one implementation of an algorithm for random access iterators, and another for bidirectional iterators, for example?
As someone was pointed out in another posting, you can't use BCCL for this, since the checks fail with a compile error if a concept doesn't match. However, if you're able to define compile-time traits performing the concept check, then you _can_ overload on concepts, using enable_if. See the Concept Traits Library
(http://web.archive.org/web/20050428001254/http://neoscientists.org/~tschwin
ger/boostdev/concept_traits/libs/concept_traits/doc/) for an approach to this.
This library is no longer maintained (at least by me, and unfortunately I don't have the source available right now, but Tobias Schwinger may have it around somewhere), not at least due to the upcoming C++0x, where this is supported in the language.
The above library was mostly an experiment about how to get support for concepts in a library solution, but you really need language support to get the full effect of concepts.
That's really interesting and exactly what I was looking for a while back! According to David Abrahams (http://www.nabble.com/forum/ViewPost.jtp?post=15220025&framed=y) you can't implement all requirements of all concepts as traits though. Did you bump into this? What kind of requirements can't be implemented as traits?
That's right, there's a number of limitations on what you can detect with traits. Nevertheless, you can detect surprising much, if you bend the language enough :) A number of people have directly or indirectly contributed to the library (as stated in the acknowledgement section of the docs), not at least Paul Mensonides ("I'm fairly sure this is valid C++, but EDG and VC 7.1 crash at different parts of it..."), whose crazy^H^H^H^H^Hinteresting techniques were essential for major parts of the library's compile-time introspection techniques, such as the "has_member_*" metafunctions. Then there's Tobias Scwinger who changed the original "switch on type" implementation (using Boost.MPL) to an overload-resolution detection technique, speeding the traits up by several orders of magnitude (with a lot of traits, it could be quite heavy on compile time), and becoming a co-author of the library. Regarding what you can and can't detect with traits: Things you can detect: - Static and non-static member functions, member constants, member types and member class templates. - Much of the operators. - All the stuff that Boost Type Traits gives you can be used. Things you can't detect (without specialising the traits for the types in question): - Constructors and destructors (they don't have a name, so can't be detected using traits detecting member functions) - Operators that has to be class members, such as assignment operator, member access operator, subscript operator and function call operator. It seems like a rather arbitrary restriction to me that these have to be member functions, and it greatly reduces the ability to perform concept checks where they are involved. - Since name lookup is performed before access check, you may get a compile-time error, rather than SFINAE, if a type has a required member, but where the member is inaccessible (private or protected). Also, concept checking using enable_if is an all-or-nothing affair (either it matches or it doesn't), so if you want to implement concept overloading based on best match (for example with regard to the iterator concepts), you have to perform the ordering, yourself. There's an included example demonstrating this (in the original version of the library, this is located in libs/concept_traits/example/std_advance.cpp).
I'll have a look at your library later on today.
As mentioned in another posting, I've put it up here: http://home.broadpark.no/~terjesl/files/concept_traits_original.zip http://home.broadpark.no/~terjesl/files/concept_traits.zip Regards, Terje
Terje Slettebø wrote:
Regarding what you can and can't detect with traits: Things you can detect:
- Static and non-static member functions, member constants, member types and member class templates. - Much of the operators. - All the stuff that Boost Type Traits gives you can be used.
Things you can't detect (without specialising the traits for the types in question):
- Constructors and destructors (they don't have a name, so can't be detected using traits detecting member functions) - Operators that has to be class members, such as assignment operator, member access operator, subscript operator and function call operator. It seems like a rather arbitrary restriction to me that these have to be member functions, and it greatly reduces the ability to perform concept checks where they are involved. - Since name lookup is performed before access check, you may get a compile-time error, rather than SFINAE, if a type has a required member, but where the member is inaccessible (private or protected).
Great post, exactly what I want to know - thanks. Terje Slettebø wrote:
Also, concept checking using enable_if is an all-or-nothing affair (either it matches or it doesn't), so if you want to implement concept overloading based on best match (for example with regard to the iterator concepts), you have to perform the ordering, yourself. There's an included example demonstrating this (in the original version of the library, this is located in libs/concept_traits/example/std_advance.cpp).
Well, you could implement "get_iterator_tag" using enable_if + your concept traits and then use regular function overload dispatch. Since boost tags inherit from each other according to their respective refinement, the function overloading would select the most refined concept. This could be implemented once and or all and supplied with the concept traits library. <code> template<class Iterator> void advance_impl(Iterator it, int n, boost::random_access_traversal_tag); template<class Iterator> void advance_impl(Iterator it, int n, boost::single_pass_traversal_tag); template<class Iterator> void advance(Iterator it, int n) { advance_impl(it, n, get_iterator_tag(it)); } </code> Best Regards, Johan -- View this message in context: http://www.nabble.com/Overloading-on-concepts-tp17104187p17144518.html Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (5)
-
Andrew Sutton -
Anthony Williams -
Johan Torp -
Michael Fawcett -
Terje Slettebø