From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-12-29 00:06:17
"Dan W." <danw_at_[hidden]> wrote in message
> 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?
> 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
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<>,
> owning containers for elements requiring delete as opposed to delete?
Some have agued that this is the reason for having a delete hook like
it is much better just to use ptr_container< boost::array<X,size> > instead.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk