Hi Dave, Thanks for your review. "Dave Harris" <brangdon@cix.compulink.co.uk> wrote in message news:memo.693392@cix.compulink.co.uk... | I feel there are really two kinds of container here. The first is a | container of pointers which takes ownership of the objects it points to. | This would be a more-or-less drop-in replacement for vector<T*>. It would | allow nulls, and syntax like (*v.begin())->method(). At some point it was discussed to have a new policy that decided the indirection of the reference type. It create much attention. Still it would not give a complete drop-in replacement. | The second is a container of values which may be polymorphic. It would be | a more-or-less drop-in replacement for vector<T>. It would not allow | nulls, and the syntax would be like v.begin()->method(). Although it would | probably use pointers behind the scenes, that would be an implementation | detail not revealed by its interface. | | The present submission has tried to combine these two kinds of container. | I believe they would be better kept separate and given different names. | I'd suggest "owning_vector" and "poly_vector", or similar, since the one | is about ownership of pointers and the other is about solving the | polymorphic value problem. poly_vector is not a bad name if that was the only uses of the containers. | Incidently, I also dislike the library calling itself "smart" because that | word is too vague. Smart in what way? smart in the same way smart pointers are smart. It should give the impression of exception-safety and resource ownership. | 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? | | > * What is your evaluation of the potential usefulness of the | > library? | | Why not use vector<shared_ptr<T> > instead? That provides a simple | out-of-the-box solution without the problems with std algorithms. | | 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? Would an unindirected interface be enough? (eg, you can determine to disable cloning etc). | I have not looked at the implementation or attempted to use the library. I | read the documentation, got confused, got unconfused via this list, and | then decided it was not for me. Maybe half an hour of effort. I don't | expect my opinion to carry much weight. | | I use std containers, and have often written wrappers for containers of | raw pointers. well, that is a least interesting. Did you ever forget to implement a wrapper function with the right exception-safety? | > * Do you think the library should be accepted as a Boost library? | | No. Sorry to hear that. Thanks for the review anyway best regards Thorsten