|
|
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-05 10:10:03
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.
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.
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.
toon