Boost logo

Glas :

Re: [glas] using (boost)range or STL style interface [was: dense and sparse vectors]

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-08-04 15:03:21

David Abrahams wrote:
> Everything below the bullet list at
> describes a
> problem solved by cursors and property maps that's not solved by N1531.
> (

I'm afraid I'm not following you here. The N1531 (or N1550) proposal
*do* seperate traversal from access capabilities. But you state in the
cursor_and_property_maps.html that they do not ?

> I'll
> be happy to provide an archive on request, but I warn you that
> there's a lot of framework there and not much computation, so you
> may find it hard to read.

Nevertheless, I would be happy to look at this closer so would
appreciate if you can send me an archive so I can understand exactly
what you want to accomplish with cursors and property maps and how.

> 2. Dietmar Kuehl and I have been working on how to represent
> segmented cursors and property maps

Thanks, I'll have a look at that too.

> One great added value in a Sequence-based implementation, aside
> from the simplicity of being able to pass containers directly to
> algorithms, is composability. That is, you can pass the results of
> one algorithm directly on to another one, without declaring
> intermediate variables. That's important in a world with lots of
> views. For example,
> some_algorithm(transpose_view(m))
> as opposed to:
> some_algorithm(transpose_view(m).begin(), transpose_view(m).end())

Very strong argument indeed. In line with Neal's to-the-point argument
about being able to use a sequence/range as return value.