Re: [boost] Overloading on concepts

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2008-05-08 20:48:44

HiJohan.

>From: "Johan Torp" <johan.torp_at_[hidden]>

> Terje Slettebø wrote:
> >
> >>From: "Anthony Williams" <anthony_w.geo_at_[hidden]>
> >> 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