Consider something similar to what Glib::ustring does, only better made. If I have a sequence of characters (say, in a normal std::string) and want to use an adaptor to decode UTF-8 code points, the resulting adapted iterator returns a different type (element is char32_t), not an lvalue, and consumes a variable number of underlying elements. It's not just a transform_iterator because it consumes a variable number of underlying elements. It's not writable because a new value might encode a different number of underlying elements than the one it is replacing. I think I need to implement it directly from iterator_facade, not one of the more specialized classes already provided. Am I mistaken? What is the traversal type? Random access is _possible_ just not efficient. To move forward n locations it has to increment n times. ++ and −− are fine. There is indeed a well defined distance between two iterators, but I don't want to encourage that kind of thing and hide the inefficiency. But, I see that relational operators are defined for random access (only), not for bidirectional? Why is that? Note that relational operators for the proposed type _are_ efficient, as it can defer to the underlying iterator. I knows which is greater, just not by how much exactly. The template argument for Difference, in the tutorial, mentions "distance between any two addresses in memory". But the distance between two locations is not the same as the difference in bytes. Is this being implied? After all, the example is a linked list and the distance from one node to another, in hops, has no relation to the address at all. Is Difference something I need to worry about?