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