David Abrahams wrote:
Whether results should be lazy (as in Fusion) or greedy, as in standard algorithms, or whether both variants should be provided somehow, are interesting questions. The answers change the usage pattern, i.e.:
copy(transform(s1,op), output)
or output = transform(s1,op) // if output supports it
vs.
transform(s1,op,output)
WRT Fusion, I am re-considering its laziness. MPL algorithms are sequence preserving. Fusion is not, due to laziness. i.e: transform(tuple, op) does not return a sequence like tuple. instead, it returns a view (transform_view). However, I realize now, that in most use cases, I noticed that I had to eagerly generate the result into a tuple almost as immediately after each transform step. After leaving this for a while in my thought queue, and after implementing phoenix2's lazy STL algorithms, I realized that the lazy Fusion algorithms could as well be implemented as phoenix2's lazy fusion algorithms. If I implemented Fusion algorithms as non-lazy and sequence preserving like MPL, I could easily write lazy fusion algorithms through phoenix. I am still unsure about which is the best way to go. I just thought I'd share my recent thoughts on the issue. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net