Boost logo

Boost :

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-07-01 22:45:13

On Tue, Jul 1, 2008 at 8:28 PM, Giovanni Piero Deretta
<gpderetta_at_[hidden]> wrote:
> On Tue, Jul 1, 2008 at 12:50 PM, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
>> Isn't the whole point of creating an expression template
>> based-approach to create these (maybe using proto I guess) and allow:
>> 1. The same placeholders used in Phoenix+Proto to be used in the pipe
>> syntax in range_ex (or an imaginary new RangeEx implementation).
>> 2. Allow for efficient (i.e., compiler optimized/assisted)
>> implementations of the composition of these new
>> views/ranges/iterators.
> Of course. My point is that you need very few beyond what is available
> in Phoenix. Just the ability to have
> a placeholder which doesn't make the whole expression lazy ( i.e.
> foo(_) should be the same as unlambda(bind(foo, _1)) ).

When you say the whole expression lazy, do you mean even the for_each?

Why don't you want the range generation functions (or the pipe syntax)
return a lazy range? Perhaps something that only gets activated when
begin(range) and end(range) are invoked?

>> ?
>> Although I do like how this looks granted that you are using C++0x's
>> auto -- in today's C++, the reason I used the STL was to avoid having
>> to compute the actual type produced by the pipe syntax.
> You need to know the result type of the reducer even in your example,
> so it is not specific to the 'sugared' syntax :)

for_each ( range(source) | take(10) | map(mapper()), cout << arg1 <<
endl ); // with Phoenix

Assuming that there's a boost::for_each(range<T>, F) -- I don't think
I need to know the result type of the reducer in that example. Am I
missing something?

>> Maybe this is
>> why Dave is asking for a better BOOST_TYPEOF. ;-)
> Well, as long as the result type of the final fold has been
> registered, it should work out of the box.

Of course, registered manually you mean? Or do you rely on
compiler-specific 'typeof'?

>> Okay, but shouldn't this composition with transform_iterator be done
>> with something that 'comes out of the box'?
> It is ok to provide a zip+transform in a single function, but it is
> not a primitive. Let's call it zip_with, its result type should be
> transformed_range<zipped_range<RangeTuple> , Mapper>, we do not need
> an explicit zippedWith_range (and in fact it would make deforestation
> harder).

Shouldn't the deforestation already have happened in the zipping and
application of the function to yield another tuple?

Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Boost list run by bdawes at, gregod at, cpdaniel at, john at