"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

| | Are the authors of range libraries aware of | http://boost/libs/utility/Collection.html?

yes.

| Just wanted to make sure.

no worries.

I asked Jeremy if I could use it as a basis for my docs...so I did...but then most changed so only a few of Jeremy's original words are left. The results are in libs/range/doc/range.html IIRC.

Is one redundant now? Should one concept refine the other (refactorization)? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:uoekp5v5w.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

| > I asked Jeremy if I could use it as a basis for my docs...so I | > did...but then most changed so only a few of Jeremy's original words are left. The results are in libs/range/doc/range.html IIRC. | Is one redundant now? Should one concept refine the other | (refactorization)?

Jeremy's collection concept had the same motivation as the range concept: to lower requirement on container types.

However, Jeremy's concept talk about member functions and still mentions a reference type that behaves like a normal reference, but which doesn't have to be it. In the range concepts that is all gone.

So my personal feeling is that collection.html is redundant now.

It's not redundant until you make all the code that relies on it work with models of the more-general Range. Sounds like Collection is a refinement of Range. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:ullft2bnb.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

| > So my personal feeling is that collection.html is redundant now. | | It's not redundant until you make all the code that relies on it work | with models of the more-general Range.

what code?

For example, the Multi Array library uses the collection concept. In addition to code, you'd need to update the docs.

| 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. No? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:un008zsze.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

| > what code? | For example, the Multi Array library uses the collection concept. | In addition to code, you'd need to update the docs.

ok, sorry...I did not know that it was actually used in boost.multiarray...the version I found of the docs was in the files section.

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

Why not? Is something else missing from collection that is present in range? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

"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

What we need is somthing like this: namespace boost { namespace range { namespace detail { template <class T> typename range_iterator<T>::type begin(T& x) { return x.begin() } template <class T> typename range_iterator<T>::type adl_begin(T& x) { return begin(x); // will use ADL if a begin is defined } } template <class T> typename range_iterator<T>::type begin(T& x) { return detail::adl_begin(x) } }} Then you change the Range concept to require that boost::range::begin(col) works. Of course, Collection will only be a refinement if there is no incorrect begin hanging around for that type... so maybe this is fruitless. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:ur7pkurnp.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

| > 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 | | What we need is somthing like this: | | namespace boost { namespace range { | | namespace detail | { | template <class T> | typename range_iterator<T>::type begin(T& x) | { | return x.begin() | } | | template <class T> | typename range_iterator<T>::type adl_begin(T& x) | { | return begin(x); // will use ADL if a begin is defined | } | } | | template <class T> | typename range_iterator<T>::type begin(T& x) | { | return detail::adl_begin(x) | } | | }}

apart from the adl stuff, it already is like that. Did you mean to put in the range namespace to avoid problems with classes in boost?

No, I mean so that the concept can be described in terms of boost::range and Collection can become a refinement of Range.

| Then you change the Range concept to require that | boost::range::begin(col) works.

hm...yeah...one could perhaps state both syntaxes as part of the concept, eg

Valid expressions ============ begin( a ) or a.begin()

No, you have to say boost::range::begin(col). Otherwise they could make a.begin() valid but begin(a) invalid, and that would break boost::range::begin.

| Of course, Collection will only be a | refinement if there is no incorrect begin hanging around for that | type... so maybe this is fruitless.

well, I agree that we have not got it complete right yet.

perhaps the Range concept could specify

Primary Template Behavior ================== return a.begin()

?

Wha??? What do primary templates have to do with this?

And maybe we don't have to talk about collection as a refinement; maybe a new term is in order, like "act", sa in "all Collections may act as Ranges".

... provided that "..." Or, we could say that certain refinements of Collection are also refinements of Range. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

Thorsten Ottosen <nesotto@cs.auc.dk> writes:

| "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "David Abrahams" <dave@boost-consulting.com> wrote in message news:ur7pkurnp.fsf@boost-consulting.com...

[snip, adl_begin()]

| > apart from the adl stuff, it already is like that. Did you mean to | > put in the range namespace to avoid problems with classes in boost? | | No, I mean so that the concept can be described in terms of | boost::range and Collection can become a refinement of Range.

I see.

| > | Then you change the Range concept to require that | > | boost::range::begin(col) works. | > | > hm...yeah...one could perhaps state both syntaxes as part of the concept, eg | > | > Valid expressions | > ============ | > begin( a ) | > or | > a.begin() | | No, you have to say boost::range::begin(col). Otherwise they could | make a.begin() valid but begin(a) invalid, and that would break | boost::range::begin.

I don't like this circular dependency on the concepts: Range has a special meaning if the argument is a Collection

?? special meaning ??

, yet Collection is supposed to refine Range.

| > perhaps the Range concept could specify | > | > Primary Template Behavior | > ================== | > return a.begin() | > | > ? | | Wha??? | | What do primary templates have to do with this?

it is the behavior of the primary template that makes coillections act as Ranges.

What primary template?

| > And maybe we don't have to talk about collection as a refinement; | > maybe a new term is in order, like "act", sa in "all Collections may | > act as Ranges". | | ... provided that "..." | | Or, we could say that certain refinements of Collection are also | refinements of Range.

hm...it doesn't sound right, does it?

No, it's not something we'd need to say.

boost\libs\range\doc\external_concepts.html

described the idea of external and internal versions of concept, roughly correponding to whether functions are free-standing or members.

Eeew!

In that terminology, we could say

1. Collection would be a refinement of InternalRange 2. ExternalRange will, by definition, work with all corresponding InternalRange

Except that if it relies on ADL, it's not "by definition" because an unrelated begin() with the wrong semantics could be defined. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com