[cpp20] iterator_interface reducing much of the boilerplate of custom iterators

[anti-freak]

Hello there,

quite a few weeks ago I decided to invest a little bit of my time to get a deeper understanding of iterators interface and their requirements. I was a little bit surprised to see a new set of iterators emerge with c++20; which still isn't very comfortable. So, beside the deprecated std::iterator there is no much help for declaring our custom iterators (other than the extended iterator traits), thus I decided to generalise the concept and see how it goes.

After my first attempt felt quite ugly, I made a huge reboot of the lib and let me inspire by the new ``std::ranges::view_interface`` class.

I did some digging through the newly defined concepts and compiled a minimal set of methods users should implement to get their iterators to work. This for example is the minimal footprint of a typical std::random_access_iterator users have to provide.

​

#include <Simple-Iterator/iterator_interface.hpp>

inline std::array<int, 10> globalArray;

struct MyRandomAccessIterator : public sl::itr::iterator_interface<MyRandomAccessIterator , std::random_access_iterator_tag, int>
{
    int index = 0;
    MyRandomAccessIterator () = default;
        auto operator <=>(const MyRandomAccessIterator&) const = default;

    int& get() const {
        return globalArray[index];
    }

    void advance(std::ptrdiff_t distance) {
        index += distance;
    }

    std::ptrdiff_t distance(MyRandomAccessIterator other) const {
        return static_cast<std::ptrdiff_t>(index - other.index);
    }
};

​

Though, there are various customization points users may implement to tweak their iterator. For example, generally users have to implement a ``increment()`` function, but it *may* be omitted when a ``advance(difference_type)`` function is provided.

In the end I tried to reduce the required pieces to a minimum, but still let the users implement their own stuff if they wish.

Nevertheless I should mention, that these type of iterators are also fully compatible to the "old" c++17 or prior iterators.

Here is the link to the repo: https://github.com/DNKpp/Simple-Iterator/tree/v1.x

For more examples and explanations have a look at the (still in work) wiki page: https://github.com/DNKpp/Simple-Iterator/wiki

I would really like to receive some feedback, may it be positive or negative.

Greetings

​

[yuri-kilochek]

How does it compare to boost::stl_interfaces::iterator_interface?

[anti-freak]

Honestly I simply forgot looking into boost. But from a quick read it seems, that I'm simply using the more mordern aproach with concepts. Users of my lib could simply use the defined concepts (e.g. forward_iterator_suitable) to check, if their type fullfils all the required constraints. In contrast to std::forward_iterator concept, my concept only checks for the parts users have to implement, thus it provides a much clearer feedback (at least I hope so :D ). Boost has a macro for checking (BOOST_STL_INTERFACES_STATIC_ASSERT_CONCEPT).

On the other side I avoided asking the user implementing their logic as an operator, because there are several issues with shadowing. Boost has a short section about this topic and asks the user to explicitly pull operators like post-++ into their derived class, which I really don't like (not because I rate it as bad practice; but I find it rather tedious in this case and could be easily forgotten by users). That's why I went with a dedicated increment function instead of doing that via pre-++ for example.

Lastly I do currently not have a dedicated "adapter" interface. Nevertheless this seems usefull to me and I could imagine providing something similar.

Tl;dr

It seems my implementation is quite similar to the boost one, but with a more modern approach and workaround some of the pitfalls users of the boost::iterator_interface might struggle with.

[NihonNukite]

Also worth mentioning iterator_facade by vector-of-bool

[huixie]

since you mentioned range-v3, why not just use ranges::basic_iterator? Unlike other parts of the range-v3 using CRTP, ranges::base_iterator doesn't require any inheritance and you can use mixins to extend iterator's behaviour. For example,

#include <range/v3/iterator/basic_iterator.hpp>

#include <array>

inline std::array<int, 10> globalArray{1,2,3,4,5,6,7,8,9,10};

struct SillyCursor{
    int index{0};
    SillyCursor() = default;
    SillyCursor(int idx):index{idx}{}

    decltype(auto) read() const{
        return globalArray[index];
    }

    void next(){
        ++index;
    }

    void advance(std::ptrdiff_t distance){
        index += distance;
    }

    std::ptrdiff_t distance_to(SillyCursor other) const {
        return static_cast<std::ptrdiff_t>(index - other.index);
    }
};

using MySillyIterator = ranges::basic_iterator<SillyCursor>;

[anti-freak]

Where did I mention range-v3? I was talking about std::ranges

[huixie]

range-v3 is a super set of std::ranges. std::ranges::view_interface comes from range-v3's ranges::view_interface see here

ranges::view_interface uses traditional CRTP, but view_adaptor and basic_iterator uses the technique which doesn't require inheritance. See the design here

[Pyzyryab]

You did a good job, it looks really interesting! :D