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:
>>>>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:
> some_type tv( transpose_view(m) ) ;
> some_algorithm( tv.begin(), tv.end() ) ;
> 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 www.boost-consulting.com