From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-05-11 12:19:15
"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 bounds
>of a range.
Can you ive some examples of this explicitness?.
>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 tries to see two containers. I'm not entirely convinced
>this is the way to go.
Neither am I. I think I'm actually for making the second arg. an iterator.
I originally thought it was good because one could do certain assertions on
size of two containers, e.g:
copy( const C1&, C2& )
assert( size( C2 ) >= size( C1 ) );
but we loose a lot of flexibility by only allowing the C2.begin() iterator
to be passed.
>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.
How would his range phrasing sound like?
>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 :¬ )
there is no such paper, but I guess it would need to go into the
of its stil-to-be-written documentation. But I'll summarize it as follows:
syntactic sugar, easier, shorter algorithm use
>I'll make sure it is mentioned on Monday and see if we can drum up some
>interest ;¬ )
I'll use a couple of minutes on changing the third second parameter to an
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk