Re: [boost] some ptr_container issues

From: Ross Boylan (ross_at_[hidden])
Date: 2005-07-14 12:46:53

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