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
> 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
> 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
>> 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
>> 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
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.