From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-05-10 09:26:01
First, you might want to look at this posting from not so long ago
I didn't get that much feedback on that :-(
"Alisdair Meredith" <alisdair.meredith_at_[hidden]> wrote in message
> 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>
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk