"Ross Boylan" <ross@biostat.ucsf.edu> wrote in message news:20050714174653.GQ3265@wheat.boylan.org...
On Thu, Jul 14, 2005 at 03:22:32PM +0000, Thorsten Ottosen wrote:
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 should note for the record that this is easy to work around, at least for moving a single element. From memory, if i is an iterator into a, you can move it to b with b.push_back(a.release(i).release())
right. when I upgrade the library, I want to support std::auto_ptr better so we just say b.push_back( a.release(i) );
I suspect this might be a bit less exception safe than transfer.
yep. no strong guarantee for more than one element.
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?
Since the docs on transfer are cast in terms of abstract types, you might want to note that it only works with the same type.
true.
...
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?
I think even a note saying "same semantics as corresponding standard containers" would do. I think documenting it explicitly for all the mutating operations would be very tedious and unnecessary, unless there is some subtlety that isn't obvious with a simple mental model of what's going on.
agree.
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() ?
Yes.
yeah, I guess it should throw bad_index. br -Thorsten