[boost] Re: [review] Formal review of the Smart Container library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-09 09:09:19

Hi Dave,

Thanks for your review.

"Dave Harris" <brangdon_at_[hidden]> wrote in message
news:memo.693392_at_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