From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-09 09:09:19
Thanks for your review.
"Dave Harris" <brangdon_at_[hidden]> wrote in message
| 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
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
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
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
with the right exception-safety?
| > * Do you think the library should be accepted as a Boost library?
Sorry to hear that.
Thanks for the review anyway
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk