New subject: [Range] Proposal to add a new range adaptor (first_nd), or modify sliced

26 Aug 2012

      Hi,

Problem:
Get the first N element of a SinglePassRange. It is not possible with
sliced, because it requires RandamAccessRange.
(Similar discussion was on the list about this in 2011 January:
http://lists.boost.org/boost-users/2011/01/65757.php)

Possible solutions:
A)
Modify sliced implementation to use std::advance instead of
boost::size. (Boost::size calls operator+ on the end iterator of the
adapted range, that is why it requires the random access.)
However using std::advance is not efficient in case of iterators which
are not random access ones. I think this efficiency problem is the
reason why the author(s) decided to not use std::advance, but rather
boost::size. So this is not a real solution.
B)
Introduce a new range adaptor, which has an underlying adapted
iterator with a "count" member:
template <class Iterator>
class first_n_iterator : public
boost::iterator_adaptor<first_n_iterator<Iterator>, Iterator>
{
        ...
        first_n_iterator(const Iterator& it, std::size_t n)
                        : first_n_iterator::iterator_adaptor_(it),
initial(it), count(n) {}
        ...
        void increment() { ++(this->base_reference()); ++count; }
        bool equal(first_n_iterator const& other) const
        {
                return this->initial == other.initial && this->count
== other.count;
        }

        Iterator initial; // used to be able to differentiate ranges
        std::size_t count;
};
One can find the whole solution and the test for it attached
(first_nd.hpp, first_nd_test.cpp). I think this is more effective than
a sliced implementation with std::advance would be.

The structure first_nd could be changed to support two parameters, so
one could provide the start position too (so it wouldn't be fixed to
zero). In the implementation (first_nd_range) std::advance could be
used to point the starting iterator to the start position. However in
this case we would get the same functionality as slice now has ...

I am asking the boost community,
1) Would it be useful, to have such a new range adaptor?
If yes,
    -- what would be the best name for it (first_nd is not the best, I know) ?
    -- I would be pretty enthusiastic to contribute it to boost.
2) Are the upper arguments valid against the current implementation of
sliced? If yes, would it worth to change it to a similar to first_nd
one? Or maybe, it would even be better to specialize sliced_range
based on the iterator_tag of the range, what do you think?

Best Regards,
Gabor

[Range] Proposal to add a new range adaptor (first_nd), or modify sliced

Gábor Márton

Nathan Ridge

Nathan Ridge

Neil Groves

Akira Takahashi

Szymon Gatner

Jeff Flinn

Michel Morin

tags

participants (1)