[boost] Re: Re: [Formal review] Collection Traits library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-05-07 04:51:47

"Pavol Droba" <droba_at_[hidden]> wrote in message news:20040507074749.GI20346_at_lenin.felcer.sk...
| On Fri, May 07, 2004 at 09:59:44AM +0200, John Torjo wrote:

| > IMO Range library is a too general name, since this is actually just a
| > tool to find the metadata (traits) about a range. (In other words, how
| > will Matt and me call our library? ;) )

I think that decision is best made sooner than later.

| > And we can think of end(),begin(),... functions as some helpers built on
| > top of the library.

Here's my view of a Boost.Range as John/Matthew are working on.

- It is an analog to Boost.Iterator with
  * adapters for quick coding of ranges
  * a number of range concepts
  * a bunch of special ranges like istream_range, indirect_range

The other part of Ranges is algorithms that work on them and it need not be bundled
with Boost.Range. For example, most string algorithms works on ranges and are part of their
own library.

Back to our original problem; what do we call this library under review if it's not Boost.Range nor
Boost.RangeTraits? Some new possibilities

Boost.RangeAdapter
Boost.ExternalRange

remark: people haven't said much about the name ExternalConcept, but maybe AdaptedConcept would be better?
ie this library would be implementing the AdaptedRangeConcept?

| > Also, another suggestion:
| >
| > How about a range_traits class:

[snip]

| There was a long discussion about this issue some time ago. Monolitic
| class is not an acceptable solution, due to several reasons.

the reason is IIRC that one can seperate functionality into several independent headers.

br

Thorsten.