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
> http://tinyurl.com/7hcka#problems-with-c-03-iterators describes a
> problem solved by cursors and property maps that's not solved by N1531.
>
> (http://boost-consulting.com/projects/mtl4/libs/sequence/doc/html/cursors_and_property_maps.html#problems-with-c-03-iterators)
>
>

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.