On Mon, Mar 2, 2009 at 3:36 PM, David Abrahams <dave@boostpro.com> wrote:
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@think-cell.com 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?"
My understanding of an expression like rng | filter(pred); is that the range resulting from it never exists independently, but rather each element is determined by the application of the filter(s) from the source range on demand.
although in total could not be as efficient as a traditional sort.
What did you have in mind, using partial_sort?
The implentation of lazy iterators is easy for simple filters, but less obvious for things like sort, in which case presumably the whole of the source range must be available before any output iterator can be evaluated. I didn't really have any specific algorithm in mind, only that the result range need only support sequential iteration, and so each evaluation of the resulting range only needs to provide the next element. That's probably obvious. Sorry.
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.
Maybe, that would remove the requirment of immutability of the source range, but OTOH might be expensive. Alternatively the result range might iterator through a range of pointers, which would be cheap, but course prone to failure if the pointed to element is destroyed. No answer really, just thoughts.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ACCU - Professionalism in programming - http://www.accu.org