[boost] Re: What is the status of Container algorithms in sandbox

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