"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote in message news:d3dqbf$gk6$1@sea.gmane.org... | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | news:d3d7uk$mm2$1@sea.gmane.org... | > | How else could they be implemented? | > no idea. | So, maybe then derive from runtime_error, despite not safe ctors, | like from std containers? | | > | If you scap them, no additional algorithms are needed, | > | or you didn't provide some? AFAIK all std algorithms works just fine | > with | > | ptr_vector<T>::iterators, I just don't see any reason they shouldn't. | > | > no. you can't, eg., write sort() when the type is copyable (which is very | > common). | Now I see, it will work on some libraries where it is guaranteed that a user defined swap will be found. | I think we can't think that some algorithms are more important | than | others, so we should implement them all. well, I think there is a key number of few algorithms which cover 99.9 % or the use cases. In partucular, I think sort() merge() erase_if() unique() is good enough. | Should they be implemented in namespace boost (for compilers that support | Koenig lookup), | or in namespace std as overloads? they should be member functions to reflect their special semantics and to follow the example of std::list.. | I can implement that algorithms, if you'd like to. I've basically done it, but thanks anyway. -Thorsten