Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at