"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote in message news:d35mcn$5pg$2@sea.gmane.org... | "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? no idea. | 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? I'm thinking unique sort merge erase_if | 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). -Thorsten