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-05 11:13:18

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

> Neal Becker wrote:
>>>> some_algorithm(transpose_view(m))
>>>>as opposed to:
>>>> some_algorithm(transpose_view(m).begin(), transpose_view(m).end())
>> The issue I run into is where transpose_view(m) is a function that can't be or
>> shouldn't be called twice - it might, for example, modify it's argument, or
>> it might be expensive.
> I agree. OTOH the problem can be worked around by writing:
> <code>
> some_type tv( transpose_view(m) ) ;
> some_algorithm( tv.begin(), tv.end() ) ;
> </code>
> Of course it's very difficult to warn users at compile time that they
> can't write the expression as you wrote it so it's an accident waiting
> to happen, I realise that.

More to the point, it's often very difficult or impossible to write

> A point that needs to be taken into account though is that the
> iterators-as-everyone-knows-them can be just plain pointers in many
> cases and compilers are in general more capable of optimising
> compiler-arithmetic than some user-defined-iterator-object.

That's a completely separate issue from whether a range-style
interface is a good idea. Ranges can be delimited by iterators (as in
Boost.Range) or by cursors (as in my work). Also, pointers make fine

> But again, don't get me wrong: I see the value of a range or
> cursor-and-property-map style interface, I'm just saying that IMO we
> need 'scientific' proof of the best approach before deciding.

I don't know what kind of 'scientific proof' you are expecting to see.
Do you want to get 100 numerical programmers in a room and test which
approach they can use more easily?

Dave Abrahams
Boost Consulting