On Mon, Aug 15, 2011 at 4:37 AM, Gordon Woodhull <gordon@woodhull.com> wrote:
+1
Please use standard iterator concepts and provide the expected behavior. Emulating bidirectional or random access iterators on top of a forward iterator is never good. People can use std::advance if they really need to.
It's not just an issue for really long strings. Consider someone trying to read a moderate sized string backward. If only forward access is possible efficiently, there should be no operator--().
On Mon, Aug 15, 2011, Phil Endecott wrote:
Err...
No, I disagree. I should be able to have a string as large as my virtual memory will allow, and it should continue to perform according to its documented complexity guarantees however large it gets. For example, I have an IMAP mail server that uses std::string internally. This is not code that needs to be especially fast, but it does require that O(1) operations don't become O(N) operations, or that O(N) operations become O(N^2) operations.
Ok I got what you mean. I think it'll be easier to just remove the decrement function completely. During implementation I also wondered if there is any real use for reverse code point iterator, but since I still got time I just implemented it anyway to leave it for just in case. (Actually it's also because I don't know if there is any way to conditionally let the code point iterator inherit from either std::forward_iterator or std::bidirectional_iterator)