One doesn't usually combine lazy and immediate algorithms, right, no?
Isn't the distinction really about tertiary vs. binary operations (operator+ vs. operator+=) rather than laziness or eagerness? I can see that for tertiary (non-in-place) algorithms, you may always want laziness if the compiler supports it efficiently, ideally writing something like: vector<int> vecn; vector<double> vecf=transformed( vecn, func ); where the assignment forces evaluation. This is possibly just as efficient or even more efficient than vector<int> vecn; vector<double> vecf; std::transform( vecn.begin(), vecn.end(), back_inserter( vecf ), func ); But there may be cases where you want the binary (in-place) form, for example: vector<int> vecn; transform( vecn, func ); // func is int -> int sort( vecn ); // sort cannot be done lazily In this latter case, I don't see how you can do without an in-place algorithm, which IMO should be named differently. Or is the idea to do this: vector<int> vecn; vecn=transformed( vecn, func ); // overwriting the range that the adaptor is still working on? sort( vecn ); // sort cannot be done lazily I don't feel comfortable with it. Some adaptors are o.k. with it (transform), while others (say, duplicate each element) are not. For some (slice), it will depend on the implementation of operator=. And the compiler won't warn you. Arno -- Dr. Arno Schoedl · aschoedl@think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229