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.