From: Alisdair Meredith (alisdair.meredith_at_[hidden])
Date: 2003-05-10 10:41:16
Thorsten Ottosen wrote:
> Sorry for asking, but what is the BSI panel?
Sorry, BSI = Britsh Standards Institute.
> It already works that way. You should also take a look at
> container_traits.hpp to see how typdefs are factored out.
> 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.
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. I extend this notion slightly by making my definition of a
range include the interface of the standard containers, namely the
Your library seems much more focused on making the library work with
containers, a different concept.
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.
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.
> > 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).
More feedback would definitely be good! <g>
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 :¬ )
> Here is what I propose: you should take a look at the way the implementation
> and give me some feedback.
I'll make sure it is mentioned on Monday and see if we can drum up some
interest ;¬ )
-- AlisdairM Team Thai Kingdom
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk