In-Reply-To: <ck8rf2$njl$1@sea.gmane.org> nesotto@cs.auc.dk (Thorsten Ottosen) wrote (abridged):
At some point it was discussed to have a new policy that decided the indirection of the reference type.
I feel the kinds of container are so different that it isn't appropriate to have a user-level policy which turns one into the other. It might make sense for them to share some common implementation, though.
It create much attention.
Indeed. My biggest problem was understanding what the library was, other than a grab-bag of features. The access syntax, for example - I sometimes felt it was a stand alone feature - that it would make just as much sense to have a vector<shared_ptr<T> > or vector<T*> that used the v.begin()->method() syntax, rather than something which flowed out of the specific intent of ptr_vector<T>. I suppose a policy approach might be appropriate if the same policy could be applied to all 3 kinds of vector. However, I am not keen on having 2 syntaxes for doing the same thing in the first place. I'm happy to use pointer syntax for things which are pointers.
smart in the same way smart pointers are smart. It should give the impression of exception-safety and resource ownership.
"Smart" suggests neither of those things to me.
| I am bothered by the libraries interaction with std algorithms. For | example, std::remove_if<> doesn't work with the container's iterators. | That makes it, at best, a low-level library that needs to be managed | carefully.
Ok, what do you suggest we do instead?
I don't know.
| The present library claims performance benefits, but if I need those | I'd write my own wrapper for vector<T *> which did exactly what I | needed and no more.
Could you enumerate what exactly you need and maybe tell why if a library suported more than you needed, but you didn't use that extra stuff, it would still be a bad thing?
Exactly what I need depends on circumstances. For example, I don't always need to let client code enumerate the container's contents. A container which allow that would need to be wrapped by a class which hid those members, because I don't like my classes to publish more interface than they need to.
Would an unindirected interface be enough? (eg, you can determine to disable cloning etc).
I'm not sure what you mean.
Did you ever forget to implement a wrapper function with the right exception-safety?
I don't believe I've ever had a problem in that area. -- Dave Harris, Nottingham, UK