Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at