Re: [Boost-users] [Range] Sliced range adaptor, alternative for non RandomAccessRanges?

Subject: Re: [Boost-users] [Range] Sliced range adaptor, alternative for non RandomAccessRanges?
From: Alastair Rankine (arsptr_at_[hidden])
Date: 2011-01-31 05:58:53

On 2011-01-27 00:35:26 +1100, Thorsten Ottosen said:

> Den 25-01-2011 07:22, Alastair Rankine skrev:
>> I don't know much about the internals of the sliced adapter, but could
>> it be changed to work a similar manner to counting_range, in order to
>> locate the relevant slice of the input range? This would allow it to
>> operate efficiently on Forward Ranges.
>> 
>> Failing this, is there an efficient alternative to the above example?
> 
> make_iterator_range() have similar functionality.
> 
> I guess it would make sense to extend sliced() to
> work in terms of advance() too, so it can work even with input iterators.

Yeah I think that would be useful.

make_iterator_range is useful but not particularly efficient for the 
usage I have in mind, which is as follows. Basically I have a set of X 
and I want to construct a string representation, but truncate it if it 
gets too long. In other words I really only want the first 20 elements 
or so (think a log entry for example).

The problem with make_iterator_range is that it uses std::advance from 
the end of the input range to make the new range. So that's basically a 
walk from the end of the set to (almost) the begining, which is O(n) or 
so. All this to get the first 20 elements of a set, seems a bit 
wasteful.

BTW there is a (minor) bug in the documentation for sliced() [1]. The 
example code produces the output "3,4,5," not "3,4,5" as stated. The 
trailing comma is an artifact of intended behaviour of 
std::ostream_iterator as I understand it.

Thanks,

[1]: 
http://www.boost.org/doc/libs/1_45_0/libs/range/doc/html/range/reference/adaptors/reference/sliced.html