From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-09-02 17:03:38
"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message news:ch7fj0$vbj$1_at_sea.gmane.org...
| "David Abrahams" <dave_at_[hidden]> wrote in message news:un008zsze.fsf_at_boost-consulting.com...
| | > | Sounds like Collection is a
| | > | refinement of Range.
| | >
| | > well, I dropped the external/internal concept definitions in the
| | > range docs, so currently ranges are defined by free-standing
| | > functions and metafunctions and not members.
| |
| | If you have generalized free-standing functions/metafunctions that
| | work for STL collections, they should work for the Collection concept
| | too.
|
| yes, of course. but that doesn't make a collection a refinement of a range.
Let me explain a little better this tricky situation. Since the Range concepts are described in terms of free-standing functions, we
kind of loose the ability to say a class is a model of a Range concept if that class only has member functions in its interface.
So since Collection has col.begin() and col.end() and not begin( col ) and end( col ) it is not per se a model of any Range
concept.
Boost.Range then comes with an implementation of various Range concepts for *any* class that has begin() and end() members.
So when this header with this implementation is included, all Collections model certain Range concepts; otherwise they do not.
And since Ranges are complete decoupled from the class/member function idea, it does not make sense for classes to refine these
concepts.
hope it helps
Thorsten