| > Pavol uses it havily in his string library. The "dangerous" thing would be not to put | > computation of the end-iterator out-side the loop, eg. | > | > for( iterator_type_of<T>::type i = begin( c ); i != end( c ); ... ) | > ^^^^^^^^^^ ^ | > is not good. But one wouldn't do that anyway. And if one did it, what are the chances of | > the argument being a char*? | | Too many chances are being taken here, IMO. the more chances that are taken, the less the likelihood of it all happening. | It doesn't feel right. | STL's end is guaranteed O(1) and I'm really concerned about anything | that violates that expectation. ok. I have forgotte why Pavol want to support char* at all. I mean, programming with manual insertion of null is really error-prone. If char* is considered a range, one might even say std::string s; my_algo( s.buffer() ); // oops, no terminating null! | Maybe the string algorithm library ought to use a different name for | this; for example: | | sentinel_type_of<T>::type f = finish( c ); | for (iterator_type_of<T>::type i = begin( c ); i != f; ++i) | ... A predicate like yours above is better in that context. I think Eric does that in for each. | template <class T> | typename iterator_type_of<const T>::type finish(T const& x) | { return x.end(); } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ typename const_iterator_of<T>::type br Thorsten