Re: [boost] some ptr_container issues

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-07-18 13:51:07

"Ross Boylan" <ross_at_[hidden]> wrote in message
news:20050714174653.GQ3265_at_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