Re: [boost] [SPAM (Bayesian)] - Re: Formal Review: Boost.RangeEx - Bayesian Filter detected spam

Subject: Re: [boost] [SPAM (Bayesian)] - Re: Formal Review: Boost.RangeEx - Bayesian Filter detected spam
From: Arno Schödl (aschoedl_at_[hidden])
Date: 2009-03-02 05:19:14

> 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_at_[hidden] 
Technical Director 
 
think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany 
http://www.think-cell.com · phone [phone] · toll-free (US) [phone]
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229