From: Dave Harris (brangdon_at_[hidden])
Date: 2004-10-10 16:15:55
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk