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: David Abrahams (dave_at_[hidden])
Date: 2009-03-02 10:36:40

on Mon Mar 02 2009, Robert Jones <robertgbjones-AT-gmail.com> wrote:

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

What does it mean to "iterate lazily?"

> although in total could not be as efficient as a traditional
> sort. 

What did you have in mind, using partial_sort?

> Naturally the underlying range must not change in any way, or
> all bets are off.

The right answer may be to copy the range in that case.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com