Designing a hierarchy of iterators - c++

Question

Let's suppose that I am coding a library, and I want to create a hierarchy of iterators in the same way that they are specified in the standard.
input iterator <- forward iterator <- random access iterator <- bidirectional... <- contiguous...
|| output iterator
I would like to offer a set of "generic iterators", that could be easily used for contiguous containers, like Array, to help the client to reduce the code that needs to write for an iterator.
So, first of all, I replicated std::iterator in my library.
export module iterator:legacy_iterator;
import std;
export namespace zero::iterator::legacy {
template<
iter_concepts::std_iterator_category Category,
typename T,
typename pointer_type = T*,
typename reference_type = T&
> struct iterator {
using value_type = T;
using iterator_category = Category;
using pointer = pointer_type;
using reference = reference_type;
using difference_type = std::ptrdiff;
};
}
the iterator_category concept is just a concept that makes sure that the client is passing one of the iterator category tags defined in the standard.
So, I want to offer a generic implementation of an input iterator, there we go:
export module iterator:legacy_input_iterator;
import :legacy_iterator;
import std;
export namespace zero::iterator::legacy {
template <typename T>
struct input_iter: iterator<std::input_iterator_tag, T> {
using base_it = iterator<std::input_iterator_tag, T>;
private:
typename base_it::pointer _ptr;
public:
input_iter<T>() = default;
explicit input_iter<T>(typename base_it::pointer ptr = nullptr)
: _ptr { ptr } {}
~input_iter<T>() = default;
input_iter<T>(const input_iter<T>& other) = default;
input_iter<T>(input_iter<T>&& other) noexcept = default;
auto operator=(typename base_it::pointer ptr) -> input_iter<T>& { _ptr = ptr; return *this; }
auto operator=(const input_iter<T>&) -> input_iter<T>& = default;
auto operator=(input_iter<T>&&) noexcept -> input_iter<T>& = default;
[[nodiscard]]
auto operator->() const noexcept -> typename base_it::pointer {
return _ptr;
}
[[nodiscard]]
auto operator*() const noexcept -> typename base_it::reference {
return *_ptr;
}
auto operator++() noexcept -> input_iter& {
++this-> _ptr;
return *this;
}
void operator++(int) noexcept {
++(*this);
}
[[nodiscard]]
friend auto operator==(input_iter& self, input_iter& rhs) noexcept -> bool {
return self._ptr == rhs._ptr;
}
[[nodiscard]]
friend auto operator!=(input_iter& self, input_iter& rhs) noexcept -> bool {
return self._ptr != rhs._ptr;
}
};
}
So, now, as a client, I notice that the input iterator in the library, could fit my needs, so I just create my own container, and I try to use it.
template<typename T, size_t N>
class Array {
private:
T array[N];
// code goes on here...
public:
using iterator = zero::iterator::legacy::input_iter<T>;
using const_iterator = zero::iterator::legacy::input_iter<const T>;
};
Everything is fine! I can iterate my array in range for loops, retrieve the begin and end iterators...
Now, going back to the origin, as the library creator, I want to offer at least one generic implementation for every generic category. So, I will try to implement a forward iterator, but I noticed that they must implement the same operators! But with subtle differences...
For an input iterator, after the use of operator++() any copies of the previous value are no longer validity guarantee, but a forward iterator must ensure the oposite
But also, a forward iterator:
Must satisfy legacy input iterator.
Default constructible.
Must be Multipass Guarantee changes to another copy of an iterator like incrementing/assignment (if mutable), can’t change the value read from other copies, unlike Input/Output iterators.
Operators: operator++(int) – returns iterator copy, and operator*() returns a reference to the iterator value.
And now is where I am getting totally lost. In order to follow principles like the DRY principle, or the KISS one, I got tempted to write this:
template <typename T>
struct forward_iterator: public input_iter<T> {
}
So, since the same operations and operators are required, I could use static binding (totally avoiding dynamic dispatch) and get rid out of all the code duplication, and just by changing the private T* ptr member of my input_iterator to protected, everything will look fine. But no...
Is my input iterator even implemented correctly?
Is the container or the datastructure the one who may take care about the iterator specifications? I mean, is the container the responsible for ensuring that the input iterator must be only single pass, and the forward iterator must be multipass, for example? (along with the other requirements)? or should that behaviour must be coded in the iterator?
If the inheritance approach is correct (I think that is a really bad idea), how can I express the specific requirements (if they must be encoded in the operators and operators defined by the iterator)?
How can I then, express the differences between the iterators that has the same operator overloads, without code duplication? (I have a completly different version using CRTP, that solves those problems, but I wanted to know if there's a way with the classical inheritance approach)
Disclaimer: Everything done here is for learning purposes, but as you may see, I am lost without probably basic concepts in C++, like the real implementation of an iterator based on some sort of category defined by the standard, and I just to like to have some nice help guiding me in the architechtural design (and having help with the implementation too would be really kind)