Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-04-11 02:14:54

"Pavel Chikulaev" <pavel.chikulaev_at_[hidden]> wrote in message
| "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
| news:d34bue$2ab$
| > "Pavel Chikulaev" <pavel.chikulaev_at_[hidden]> wrote in message
| > news:d3490f$ojo$
| > | "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
| > | news:d34827$vod$
| > | > 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
| > 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
| 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
| 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


| 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at