[boost] Re: Interest: Pointer Container Library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-29 00:06:17

"Dan W." <danw_at_[hidden]> wrote in message
news:6.0.0.22.0.20031228215508.027e6a40_at_pcp.softhome.net...
> Sounds very interesting to me,

I'm glad to hear that :-)

>the couple of times I've tried using
> auto_ptr's as container elements I ran into so much trouble I just gave up
> and used plain pointers.

yeah, you would have to use something like NTL for that.

> It could only be complete with "ptr_hash_map<>" though (my favorite
> container :)

Several others have requested the hash_map too. I'll can add it very easily
once I can get a
hash_map from somewhere. Does anybody know the status of the boost hash_map?

> Questions:
> What happens if I inadvertently pass pointers to statically allocated
> objects, like const strings, to push_back(), or other input functions?

you're not allowed to do that. All pointers must be heap-allocated.

> Would it be safer for push_back(), say, to take a smart pointer as input?

in some sense yes. You're thinking about giving the user a hint about the
ownership semantics. However,
since the user could also pass the address of a stack object to the smart
pointer, we have only
moved the problem. Knowing that the containers take ownership is really
neccesary to use the containers
properly; we can't protect against malice.

> What if I *want* to use pointers to const strings, i.e.: *not* to be owned
> by the pointer container, but still enjoy its other conveniences?

I have thought about this for some time, but I have not reached a final
conclusion.
In your sepcial case of strings, there does not seem to be any reason for
the indirected semantics; one should
just stick to normal containers.

For normal pointers, however, non-ownership cannot be used currently,
because auto_ptrs can call delete on
pointers in various cases. So it would require a whole new interface:

void non_owning_insert( ... );
void non_owning_push_back( ... );

and also some mean to get rid of the delete in the containers destructor and
erase() which could be either
a delete_clone() hook or a remove_owneship() member function. On top of this
you must not forget
not to use the part of the interface that returns ownership.

So I think it is not worth supporting this. IT might also be better to make
a kind of proxy that can be used with
normal containers, but I haven't thought that through.

> And, should there be corresponding array_map<>, array_set<>,
etc.?; --i.e.:
> owning containers for elements requiring delete[] as opposed to delete?

Some have agued that this is the reason for having a delete hook like
delete_clone(). However,
it is much better just to use ptr_container< boost::array<X,size> > instead.

br

Thorsten