These are assumptions that I would probably be happy to accept in my own internal-use code, but you are right to say that they are probably not appropriate for library code. For library code you would need to wrap the container with something that guarantees this behaviour in a more solid way. Out of interest, does anyone know if a std::vector that has been reserve()d guarantees anything about dereferencing beyond-the-end iterators? It would be great if they were allowed to be undefined yet certain not to segfault.
Undefined behavior. Don't do it.
I'm having precisely this problem with a home brewed strided_iterator Given a std::vector<int> 'a' containing [3,8,2,1,0,9,4,6,5,7] I would like to sort the sub range defined by every second element starting at index 1. Conceptually something like: ejg::striding_iterator<std::vector<int>::iterator> begin(a.begin()+1,2); std::sort(begin,begin+5); so that I obtain [3,1,2,6,0,7,4,8,5,9] While it works fine under g++, on MSVC it throws a segfault when applying the prefix ++ operator since it attempts to dereference the location one past one past the end. Irritating beyond belief! As far as I can see there's no way around this with bare iterators. Any suggestions? -ed ------------------------------------------------ "No more boom and bust." -- Dr. J. G. Brown, 1997