"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:ch7fj0$vbj$1@sea.gmane.org... | "David Abrahams" <dave@boost-consulting.com> wrote in message news:un008zsze.fsf@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