"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d34bue$2ab$1@sea.gmane.org...
"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote in message news:d3490f$ojo$1@sea.gmane.org... | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | news:d34827$vod$1@sea.gmane.org... | > std::out_of_range uses std::string. | Didn't know about that. Just checked standard, that's true. | Do you know why it is soo?
historical accident; the mechanism might not have been fully understood when the first standard was written.
Are they going to be changed in the next standard? How else could they be implemented? When need you throw dynamically allocated string, something should store it and remove when needed - and std::string serves that great. But when you only need to throw statically allocated char *, there is some overhead, and something may happen then. Since you can't provide two different implementation of such classes (I mean copying string and referencing string), the existent way is the only way to do it. (Of cource we can use in_place, but that's a bad way to do it IMO). And what is more important is that we just can't have another way to do (I mean not-throw-guarantee) except malloc/free which is deprecated in C++. (And even if they were not deprecated, what() may return 0, I think it's not the behaviour users are expected to see. So, I think you should derive from std::runtime_error anyway. If i'm entirely wrong, can you provide a link where this behaviour of exception derived classes was discussed and the proposed solution for it?
| So what's your decision about ptr_iterators - to be or not to be? let's scrap them and provide a few common algorithms.
What algorithms? 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.