Overloading on concepts

[Anthony Williams-3]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Andrew Sutton]

> 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@...



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Johan Torp]

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

[Anthony Williams-3]

Johan Torp <johan.torp@...> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Terje Slettebø]

>From: "Anthony Williams" <anthony_w.geo@...>

> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Michael Fawcett]

On Wed, May 7, 2008 at 2:15 PM, Terje Slettebø <tslettebo@...> wrote:

> >From: "Anthony Williams" <anthony_w.geo@...>
>
>  > 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-3]

Terje Slettebø <tslettebo@...> writes:

>>From: "Anthony Williams" <anthony_w.geo@...>
>
>> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Johan Torp]

Terje Slettebø wrote:

>From: "Anthony Williams" <[e-mail]>
> 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

[Terje Slettebø]

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@...>
To: <boost@...>
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@...>
wrote:
> >From: "Anthony Williams" <anthony_w.geo@...>
>
>  > 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Terje Slettebø]

HiJohan.

>From: "Johan Torp" <johan.torp@...>


> Terje Slettebø wrote:
> >
> >>From: "Anthony Williams" <anthony_w.geo@...>
> >> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Johan Torp]

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