"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
the
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
"motivation" section
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 ;¬ )
great. :-)
I'll use a couple of minutes on changing the third second parameter to an
iterator.
regards
-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
