Boost logo

Glas :

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

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-02 13:56:47

Toon Knapen <toon.knapen_at_[hidden]> writes:

> Neal Becker wrote:
>> I have not followed the details of this discussion. I wonder,
>> though, if the use of "range" was considered as an interface,
>> rather than stl-style iterators. I have been making extensive use
>> of boost::range for all my container needs, and have found it to be
>> more useful than iterators.
> My feeling currently is that people are familiar with the STL style
> interface while not with boost::range. AFAICT both approaches however
> can coexist so there's no harm in supporting a range-style interface as
> well.


> However having both styles of interfaces complicates matters a bit

Yes, it does. So there is _some_ harm at least.

A sequence-based interface has real advantage in terms of
> (not everybody is familiar with boost:;range, possible
> portability-problems) in respect to the added value of having both
> styles of interfaces. Additionally the question of supporting
> range-style interfaces or not is *currently* IMHO not essential to
> the linear algebra capabilities. It is already very difficult to
> find consensus on IMHO more important issues like defining a generic
> interface for different types of sparse matrices etc.

Unfortunately, the issue of "iterators or ranges" goes right to the
heart of what the generic interface for a matrix looks like.

> So my feeling is to not consider it *now*. This does not exclude
> that it might be considered in the future. And this is of course my
> current feeling but I actually have not really a real strong opinion
> on the issue.

For what it's worth, the MTL4 project is using a Sequence interface:
( or,
which is similar to the Boost.Range interface, but generalized along
several dimensions.

  - Instead of iterators, we use cursors and property maps:

  - Cursors are generalized so that the begin and end cursor for a
    sequence need not be the same type. This generalization allows us
    to do some really interesting things with fixed-size sequences,
    unrolling operations on them completely at compile-time. It also
    allows us to treat non-homogeneous sequences (e.g. boost::tuple)
    as :concept:`Sequences`. [¹]

  - We are supporting segmented cursors and property maps, per Segmentation turns out to
    be crucial for blocking, parallel decomposition, and efficient
    operation on linearized CSR matrices.

[¹] We can also solve a nagging problem with many input iterators: a
    special degenerate iterator value is often needed to use as the
    end-of-sequence indicator, which complicates the iterator's
    comparison operators and reduces their efficiency. There are a
    few other neat tricks, too.

Dave Abrahams
Boost Consulting