Re: Proposal: Sorted Vector Container

From: edbrey (EdwardDBrey_at_[hidden])
Date: 2002-01-08 20:47:15

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> Sorry, I don't think I'm picking nits here. As I understand it, if 
> an operation's postcondition doesn't hold, an error has occurred.

Agreed. It would be a bug in the library, just like an invariant not 
holding.  The postcondition I had in mind would always hold:

unsafe_insert(p, x) postcondition:
x is inserted into container immediately before p. Additionally, if 
the container was ordered prior to the call and if no element prior 
to p is greater than x and if the element at p (if any) is not less 
than x, then the container remains ordered.

Reflecting on this, the second statement of my postcondition seems 
unnecessary given sufficient exposure of the underlying container's 
semantics. That's probably what triggered the confusion.

> > My reading of this indicates that the plan is to continue to
> > _not_ give the programmer control over the insertion location.
> > This is too bad, since that would comes in handy on occasion.
> > It would be nice if the vector associative containers provided
> > the programmer control over precise insertion location.
> 
> That was the point of my proposal. It also lets you say
> 
> v.insert_with_hint(v.begin(), x); // insert at first valid location
> v.insert_with_hint(v.end(),x);  // insert at last valid location

I assume you mean your proposal for library issue 233. Your proposal 
didn't make it into the notes on the issues web page, so thanks for 
clarifying it.

Regardless of what becomes of std::multiset et. al., your proposal 
looks perfectly suitable for a vector associative container.