[boost] Re: [ptr_container] post review comments

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

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