On Fri, Feb 27, 2009 at 5:33 PM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Rogier van Dalen skrev:
Dear Neil,
Many lazy adaptors are desirable. I would continue to add more as time permits. My focus is on producing a good foundation for this version. The reviews are giving me a clearer need of what people want from the library.
Fair enough. This will be fine if many reasonable algorithms can be implemented within range_ex. However, could you state how you would integrate lazy merge() or anything that takes two or more ranges in operator| syntax? The function syntax would be: merged(rng1, rng2) I believe that the '|' syntax, however cute (I agree there!) is less flexible and less obvious than the function syntax. Therefore, I think the function syntax should be the primary one.
Currently merge(), transform(), and the set algorithms use output iterators as a substitute for return values. Rephrasing them as functions would also get rid of output iterators, which would improve their interface.
I tend to agree.
E.g. an algorithm like transform(-) should return a range.
Or perhaps we need a new syntax to enable
rng && rng2 | transformed(binary_fun())
you mean for the two ranges variant of transform? Well first you can always do this: zip(rng, rng2) | transformed (unpack(binary_fun()) obviating the need for a 2 range (or n-range) variant at all. Otherwise, may be an infix syntax would work (but it probably count as too much operator abuse [1]): rng1 ^transformed(binary_fun())^ rng2 ; Distinguishing from the 1 range and 2 range variants would be interesting. It might work better for 2-ranges only adaptors: (rng1 ^merge^ rng2) [1] FWIW, FC++ has generalized infix function object with the same syntax. -- gpd