> > Likewise, for me a container is simply one form of range, but I can
> > imagine many others. Perhaps I should take a look at the Views
> > library? To phrase the library in terms of containers seems to limit
> > it, to me.
>
> I like your approach, FWIW. It's easy enough to get an iterator
>Also, is there a background paper describing the motivation for this
>library anywhere? I am currently making big assumptions about its
>intent (you may have noticed!) so that might correct some of my
>misconceptions :¬ )
when I come to think of it, it was also nice to be able to treat arrays,
i
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Alisdair Meredith <[EMAIL PROTECTED]> writes:
>
> > This is clear when we look at algorithms that take a range for input and
> > an output iterator, eg transform. Where I see a range and an iterator,
> > your library tr
"Alisdair Meredith" :
>Hmmm, it looks like we are trying to achieve slightly different things.
>From my perspective, the standard library works with semi-open ranges
>and iterators. I am not trying to change that, merely make more
>explicit when a pair of iterators in the parameter list form the b
