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

From: Dave Harris (brangdon_at_[hidden])
Date: 2004-10-10 16:15:55

In-Reply-To: <ck8rf2$njl$1_at_[hidden]>
nesotto_at_[hidden] (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