Glas List: 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
some_type.

> 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
cursors. 
http://boost-consulting.com/projects/mtl4/libs/sequence/doc/html/cursors_and_property_maps.html#backward-compatibility

> 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