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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-05-10 09:26:01

Hi Alisdair,

First, you might want to look at this posting from not so long ago
http://aspn.activestate.com/ASPN/Mail/Message/boost/1557256
I didn't get that much feedback on that :-(

"Alisdair Meredith" <alisdair.meredith_at_[hidden]> wrote in message
news:3EBCF83A.B1A03286_at_uk.renaultf1.com...
> Preparing for the BSI panel meeting on Monday we again came across the
> topic of overloading the standard algorithms to take range arguments
> (iterator pairs.)

Sorry for asking, but what is the BSI panel?

> The motivating example came from filter_iterator in
> the new iterator_adaptors proposal, which seems more range-like than
> iterator-like.  I thought to take a look into the sandbox for precedent
> before pushing something new though <g>

good idea.

> The container_algo.hpp file in sequence_algo seems to provide what I am
> looking for already, but is phrased in terms of Containers, rather than
> Ranges.  I would like to see this extended to any object that has
> members begin/end that return iterators (and a suitable set of
> supporting typedefs)

It already works that way. You should also take a look at
container_traits.hpp to see how
typdefs are factored out.

container_traits are meant to be what Dietmar called array_traits. I talked
to Dietmar at the
ACCU conference and he didn't mind that somebody continued his work. I
really think array_traits
is a bad name, hence container_traits: they allow different types to be
treated similar as containers in generic code.
(notince that the container_traits will never work for array on a compiler
without partial class template support )

The container algorithms use the the container_traits and in particular the
freestanding begin()/end() functions. These works fine with a pair of
iterator (what you might call a range).

Now should container_traits be renamed range_traits? I don't think so
because they provide information that
wouldn't fit a range abstraction (e.g. iterator_type, element_type,
size_type ). We could put the begin()/end() function
in a separate header (range.hpp) or something.

> I have quite a lot of code that would refractor well around functions
> returning range objects.
>
> Is anyone else actively working on this at the moment?

It would be me, although I have lacked some time to finish the stuff.
Actually it would be finished if it should
not work with non-standard compilers (and if somebody would give some
feedback to my last posting).

Here is what I propose: you should take a look at the way the implementation
and give me some feedback.
I have some sparetime tomorrow which I could use for finishing a version
that works with good compilers.

best regards

Thorsten