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. 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. 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. 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. 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. 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. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062
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
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()) I suspect this might be a bit less exception safe than transfer.
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. ...
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.
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.
best regards
Thorsten
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"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
participants (2)
-
Ross Boylan -
Thorsten Ottosen