Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk