On Tue, Jul 1, 2008 at 8:28 PM, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
On Tue, Jul 1, 2008 at 12:50 PM, Dean Michael Berris <mikhailberis@gmail.com> 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.