Re: [boost] some ptr_container issues

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-07-14 10:22:32

Ross Boylan <ross <at> biostat.ucsf.edu> writes:

> 
> I'm using the cvs version (as of a couple of days ago) of the
> ptr_container library with a regular 1.32 boost.
> 
> Should transfer operations between dissimilar containers (e.g.,
> ptr_vector and ptr_list, assuming both have the same underlying type)
> work?  They don't seem to. 

and currently they are not supposed to.

> I can't quite tell from the docs (which
> define these abstractly, e.g., for ptr_sequence) whether this should
> work or not.  Previous versions of the docs made it explicit that the
> operations were templated on the type of the second container.

yes. I changed the behavior because it raised the question
of what to do if the clone_allocators/allocators are different? 

> Second, the definition of transfer does not say where the elements are
> to be inserted (i.e., whether they go before the "before" iterator, or
> whether the "before" iterator will end up before the inserted elements).
> While it's not hard to guess right with some knowledge of how the
> standard works (and even how other ptr_container functions work), it
> would be nice to be explicit.

I agree.

> Third, I didn't see any explicit discussion of circumstances that
> invalidate iterators.  Again, it's pretty easy to guess this is the same
> as the corresponding standard classes, but it's probably worth saying
> so.

Would a link to a discussion for the standard containers be sufficient
or should each function specify it?

> Finally, the discussion of exception classes does not describe the
> circumstances under which the exceptions are thrown.  Some functions do
> discuss their exceptions, but I'm not sure if they all do. 

The intention is that thay should.

> I was
> surprised that at throws bad_ptr_container_operation; I would have
> expected bad_index (this behavior *is* documented--I'm just saying it
> seems odd).
> 
> Thanks for your work on these utilities.

AFAICT, at() in ptr_vector/ptr_deque does throw bad_index and so documents
it right.

Are you referring to ptr_map.at() ?

best regards

Thorsten