Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-05-31 06:31:43


on 5/31/00 5:38 AM, Mark Rodgers at mark.rodgers_at_[hidden] wrote:

> Are users ever expected to use associative_vector directly,
> or just indirectly via vector_set and vector_multiset? If
> the latter, shouldn't associative_vector be in a detail
> namespace, and perhaps associative_vector.hpp could live in
> the detail directory??? Without documentation it's hard
> to tell... :-)

The former, actually. I would have put it in detail if I intended to protect
it.

> It doesn't compile with Borland C++Builder 4 or BCC 5.5.
> The first complaint is because there is no such thing as
> std::identity. Certainly an identity functor is useful,
> so perhaps a boost::identity would be in order. I added
> one to the top of vector_set.hpp to get the ball rolling.

Ah, thanks. An SGI STL dependency.
<snip BCB fixes>

> That made it all work and the tests then ran without error.
> Now I can try it out with some tests of my own, and will
> ponder it all further. I'll get back to you if I have
> any comments.

Thanks, Mark. Actually, I've been aiming at something else which I haven't
yet implemented, and now I realize I need a little bit of redesign to get
there. One thing I want to end up with is an indirect_vector_set<T>, IOW a
class with the same interface but which stores pointers to T instead of Ts
directly (I need stable pointers and references across inserts). So what I
really need to do is implement a node_vector<T> which provides the identical
interface to vector<T> but adds vector/reference stability (and some nice
additional strong exception-safety guarantees), and then parametrize the
vector_set on the underlying container type. Once I get there, I might as
well call it linear_set or something, since someone might want to use a
deque<T>. That's all in the pipeline.

BTW, naming suggestions gratefully accepted; I'm not in love with the names
I have.

Regards,
Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk