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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk