Boost logo

Boost :

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

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> 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

> 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 

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