Boost logo

Boost :

Subject: Re: [boost] for_each abstraction
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-11-17 12:35:48


On 11/17/2010 8:22 AM, Karsten Ahnert wrote:
> Hi,
>
> I need something like an abstraction layer for iterations over some
> range. Consider for example the following three statements, which all do
> the same, but the loop inside each for_each is different:
>
> // thrust is an STL-like interface for CUDA [1]
> thrust::device_vector< double> a1( 3 );
> thrust::for_each( a1.begin() , a1.end() , op() );
>
> std::vector< double> a2( 3 );
> __gnu_parallel::for_each( a2.begin() , a2.end() , op() );
>
> std::vector< double> a3( 3 );
> std::for_each( a3.begin() , a3.end() , op() );
>
> //maybe even
> fusion::vector< double , double , double> a4;
> fusion::for_each( a4 , op() );
>
> Is there a way or some part of a boost-library which handles the above
> three statements in a unique manner? I want to write algorithms which
> are independent of the specific for_each implementation.

What do you mean by "handles"? Do you want to just package up the
for_each function together with the sequence type you want to operate
on, effectively reducing everything to a unary function accepting the op
parameter? I don't know of such an abstraction in boost.

There was a topic that was brought up by...I'm going to say Joel Falcou,
but I may have that wrong...discussing segmented iterators and iteration
in general (I would search "segmented iterators"). I believe his use
case was enabling the use of simd instruction in the iteration, which
required special treatment of the first few and last few elements of the
range. One abstraction that makes this efficient is to push the
iteration to the responsibility of the range or sequence you're
operating on. This seems to be roughly what you might want to consider
doing here (and is basically equivalent to packaging the for_each
function up with the sequence, as I suggested above).

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk