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

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
begin/end pair.

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