自定义迭代器：如果a和b的行为不同，如何正确处理距离计算和相等比较

Question

I wrote a class PointerIterator which provides a random access iterator for arrays. I know pointers itself are valid iterators but my implementation allows to specify a unit . This unit specifies the step that is taken by each increment or decrement. The reason behind is to enable ie iteration over a row in an n x m matrix where the matrix is stored as a single array in row major order.

However, because unit is unknown at compile time it has to be specified as a ctor argument at runtime. This leads to the problem that two iterators of the same type can yield different behaviors (if unit is different from each other).

Example

Let m be a 4x4 matrix represented by a single array (in row major order).

auto rowSize = 4;
auto colSize = 4;
auto m = new int[rowSize * colSize];

// m is somehow filled with increasing numbers, like:

  0   1   2   3    
  4   5   6   7
  8   9  10  11
 12  13  14  15

To iterate over the first row of A , two PointerIterators are created (to mark the beginning and end of the range)

auto begin = makePointerIterator(m, 1);
auto end = begin + rowSize;

where makePointerIterator(pointer, unit) creates a PointerIterator for the pointer pointer with step unit .

With begin and end from above, we can use a for loop to print the first row, like:

for (auto it = begin; it != end; ++it)
    cout << std::setw(3) << *it << " ";

which yields

  0   1   2   3

To iterate over the first column, we have to change begin and end to

auto begin = makePointerIterator(m, rowSize);
auto end = begin + colSize;

Each increment (ie operator++ ) causes the pointer to step forward by rowSize which points to the next element in the column.

Printing the column can now be done by the same for loop above, which now yields:

  0   4   8  12

The problem

In order to make a valid random access iterator, I have to provide (amongst others)

difference_type operator-(PointerIterator other) const;
bool operator==(PointerIterator other) const;
bool operator!=(PointerIterator other) const;

Lets say I have two PointerIterators a and b where a.unit == 1 and b.unit == 2 which means a increases the pointer by 1 and b increases (or decreases) the pointer by 2 at each increment (or decrement).

How do I have to implement the 3 functions above while keeping the iterator standard conform?

The possible solutions that came in my mind were:

1. Preemptively check if a.unit == b.unit and if not, throw an exception.
2. Use always a.unit (which is at the left hand side of the operators), which would cause that a == b may not be equal to b == a .

Edit

I put the implementation on codereview in case someone is interested in it.

Answer 1

Iterators of the same type but with different units can be treated the same way as iterators of the same type but pointing into different containers. That is, it's the programmer's responsibility to make sure the units are the same, otherwise it's Undefined Behaviour to mix (compare or subtract) the iterators.

Answer 2

First, undefined behavior is your friend. Have "safe" operations that throw or use algebraic error types to indicate a mismatch, but the == operation can simply make the result undefined, like comparing iterators of different containers are.

Second, consider doing this:

template<class Unit, class=void>
struct default_unit_value {};

template<class Unit,
  std::enable_if_t< std::is_integral<Unit>{} >
>
struct default_unit_value:std::integral_constant<Unit, 1> {};

template<class T, class Unit=std::ptrdiff_t>
struct PointerIterator {
  PointerIterator(T* p = nullptr, Unit u = default_unit_value<Unit>::value):
    ptr(p), unit(u)
  {}
private:
  T* ptr;
  Unit unit; // actually use a compressed pair, in case Unit is stateless
};

this permits compile-time constant unit sizes to be used and mismatch errors in those cases to be checked at compile time.

auto begin = makePointerIterator<1>(m);
auto end = begin + rowSize;

constexpr rowSize = 4;
auto begin = makePointerIterator<rowSize>(m);
auto end = begin + colSize;

meanwhile, runtime variable stride is still available.

In a large number of cases you do know the element stride distance at compile time. Telling the compiler explicitly will generate better code.