"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d343vc$7ve$1@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