I wrote a C iterator to go over an std::string which is UTF-8.

The idea is for the iterator to return char32_t characters instead of bytes. The iterator can be used to go forward or backward. I can also rewind and I suppose the equivalent of rbegin().

Since a character can span multiple bytes, my position within the std::string may jump by 2, 3, or 4 bytes (the library throws if an invalid character is encountered).

This also mean the distance to a certain character does not always increment one by one. In other words, it may increment the position by a number from 1 to 4 and --it reverse subtract in a similar manner.

Is that an expected/legal behavior for a C iterator?

CodePudding user response：

Many algorithms in C work equally well with plain pointers in addition to iterators. std::copy will work with plain pointers, just fine. std::find_if will be happy too. And so on.

By a fortunate coincidence std::copy invokes the operator on the pointers you feed to it. Well, guess what? Passing a bunch int *s to std::copy results in the actual pointer being increment by sizeof(int), instead of 1.

std::copy won't care.

The properties of iterators and their requirements are defined in terms of the logical results and the logical effects of what the various operators cause to happen (as well as which operators are valid for a given iterator). Whether the internal implementation of an iterator increments the internal value, that represents the iterator in some way, by 1, 2, 4, or 42, is immaterial. Note that reverse iterators result in the actual internal pointer getting decremented by its operator overload.

If your custom iterator's implementation of the , --, *, [], , and - operators (whichever ones are appropriate for your iterator) meets all requirements of their assigned iterator category, then the actual effects of these operators on the actual raw pointer value, that represents your iterator, is irrelevant.

The answer to your question is as follows, assuming that your custom iterator is a random access iterator: if all the required operator overloads meet all requirements of a random access iterator, then the actual effects on the underlying pointer value are irrelevant.

The same holds true for any iterator category, not just random access.