[boost] Re: [ptr_container] post review comments

From: Pavel Chikulaev (pavel.chikulaev_at_[hidden])
Date: 2005-04-07 15:43:23

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message 
news:d343vc$7ve$1_at_sea.gmane.org...
> you don't want the algorithms?
Bad worded. Since I think that should ptr_iterator should be removed, no
specialized versions of algorithms are needed.

> I meant the name of the exceptions.
Ok, not so shorty then, more descriptable. Or shorty, but in namespace
ptr_container.

> yeah, well, there is not going to many other ptr_vector<T> in boost.
What about map_config? Additional security (almost for free) won't
be bad. (I mean putting in own namespace)

> nullable<T> was the best compromize I could find for the
> behavior. Adding another policy seemed overkill. optional<T>
> has some parallels, but it would not have the same meaning if we wrote
> ptr_vector< optional<T> >. ptr_vector<nullable<T>> is
> something similar to vector<optional<T>>.

I meant in other's code nullable<T> is not needed.
But I understand that optional<T> and nullable<T> are completly different.
BTW, in other languages (C#) have embedded nullable<T> which works same
as boost::optional<T>. :)

> the copy-constructor of std::string might throw; hence when constructing
> the bad_index exception-object, we might not get that far and the *wrong*
> error will be reported.

Still can't get your point. std::exception uses char *, your_exception_classes
use char *, what std::strings are you talking about?

>
> |    About bad_pointer:
> |        It's better to derive from std::runtime_error or even throw
> |        std::runtime_error("ptr_container: null pointer not allowed");
> |        You don't ever throw bad_ptr_container_operation, do you?
> |        (BTW, maybe it should be better called ptr_container::bad_operation?
> |        because your ptr_containers are not so bad :))
> |
> |    I think you shouldn't introduce and use any own classes derived from
> |    std::exception, because your containers are only extension to std
> containers
> |    that simplifies using of pointers in containers.
>
>    somebody might want to catch a more specific exception.

Then derive from runtime_error, but not exception.

>
> | So everybody expects it
> |    to work as same as std::containers when possible.
> |    It applies not only to exceptions but all member functions and so on.
> |    Example from std: Everybody expects(expected) vector<bool> to be same
> |    as any other vector<T> specialization, but it is not. Now, IFAIK almost
> |    nobody use it, and I really don't want your library to repeat
> vector<bool>
> |    failure.
> I don't think the analogy is quite the same.

That was about ptr_iterators, map::at and so on.

> |        std::sort(v.ptr_begin(), v.ptr_end(), indirect_fun<greater<int> >());
> |        std::sort(v.begin(), v.end(), greater<int>());
> |    IMO it's better to use lambda:
> |        std::sort(v.ptr_begin(), v.ptr_end(), *_1 > *_2);
> |    Don't you think this syntax is much more readable/flexible/extensible
> |    and so on? I just don't see advantages of indirect_fun, may be you do?
>
> lambda works ok when you have a simple function like <. Some people
> like the other approach I guess.

Then they can use
    std::sort(v.ptr_begin(), v.ptr_end(), std::greater<int>()(*_1, *_2));

> The main-cvs version is somewhat newer; you can access that one, right?
Didn't know that library is already there. Thanks.

--
Pavel Chikulaev