Re: [boost] Re: Constrained genericity at last? (any interest in anoperator traits/concept traits library?)

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-14 15:21:00

>From: "David Abrahams" <dave_at_[hidden]>

> Terje Slettebø <tslettebo_at_[hidden]> writes:
>
> > However, the invention of enable_if [HJW03] [JWL03] (now part of Boost)
> > opened the door to overloading based on arbitrary properties of types.
Now,
> > what we needed was techniques for detecting type properties, which could
be
> > used to create "concept type traits". Using this, we could have done,
e.g.
> > for std::sort:
> >
> > template<class Iterator>
> > typename enable_if<is_random_access_iterator<Iterator> >::type
> > sort(Iterator begin, Iterator end)
> > {
> >   // ...
> > }
>
> I should have pointed to this example more specifically in my previous
> message.  If you had a sort overload for bidirectional iterators using
> this technique, you'd have an ambiguity.

Indeed. That was also noted in the OP (about "best match", and my
std::advance example showed the manual disambiguation needed in the presence
of concept hierarchies). To get overloading on concept with "best match"
appears to need a language change (such as suggested in the papers by Bjarne
Stroustrup and Gabriel Dos Reis), or at least be very intrusive on the
functions (such as taking an extra parameter), for example:

#include <iostream>

struct bidirectional_iterator {};
struct random_access_iterator : bidirectional_iterator {};

void sort(bidirectional_iterator) { std::cout <<
"sort(bidirectional_iterator)\n"; }
//void sort(random_access_iterator) { std::cout <<
"sort(random_access_iterator)\n"; }

int main()
{
  sort(random_access_iterator());
}

As it stands, it prints "sort(bidirectional_iterator)". However, if we
uncomment the above line, it prints "sort(random_access_iterator)", showing
that it's a better match. This avoids changing existing overloads, to add
better/worse match functions, but it requires an extra parameter.

Regards,

Terje