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: Robert Jones (robertgbjones_at_[hidden])
Date: 2009-03-02 05:38:50

On Mon, Mar 2, 2009 at 10:19 AM, Arno Schödl <aschoedl_at_[hidden]>wrote:

>
> 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.

AFAICS there's no issue in principle with something like

vecn | boost::adaptors::sort

as an expression. This would result in a range that could be iterated
through lazily, although
in total could not be as efficient as a traditional sort. Naturally the
underlying range must
not change in any way, or all bets are off.

Regards, Rob.