Boost logo

Boost :

Subject: Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-10-10 13:09:17

On 10-10-2013 17:19, Nevin Liber wrote:
> On 10 October 2013 03:54, Thorsten Ottosen <thorsten.ottosen_at_[hidden]>wrote:
>> I'm ok with that, although I think it's possible to have the concept of
>> broken contracts separate from the concept of how to deal with broken
>> contracts. Is that an unreasonable oppinion?
> If you are defining the behavior, I don't see how it isn't part of the
> contract. A contract is pretty much "if you pass in X, I'll do Y".
> Look at the difference between vector::at() (wide contract with no
> preconditions) vs. vector::operator[] (narrow contract with the
> precondition that n < size()). It is impossible to violate the contract
> when calling at().

I guess it's because I view the precondition as the requirement for
correct execution. It's the same for both functions. They differ in how
they respond to an incorrect argument. UB vs. an exception.
There is a difference between general program behavior and program
correctness and contracts.

Assume we specify at() this way:

   Precondition: n < size()
   Postcondition: returns a reference to the n'th element.
   If the precondition is no met: Throws out_of_bounds

and operator[]:

   Precondition: n < size()
   Postcondition: returns a reference to the n'th element.
   If the precondition is no met: UB

At least some people don't mix normal behavior with exceptional behavior
(and so they operate with two different types of postconditions, the
normal and the one that happens in case of an exception). /The function
needs to return for its normal behavior to have happened/. I guess there
exists variations of definitions of the terms used in this thread, and
that the terms are not always defined as precise as one could want.

Hope this clarifies my view a little. There are many ways to specify
behavior, and one particular description may be enough to imply other
facts that are left unsaid.

Finally, let's take a look at

1) "precondition" is not defined. All I could find is this:

the preconditions for calling the function"

2) Postcondition is defined like this.

the observable results established by the function."

3) says:

" Requires paragraph [res.on.required]

Violation of the preconditions specified in a function’s
paragraph results in undefined behavior
unless the function’s
paragraph specifies throwing an exception when the precondition is

So at least some people have used my terminology before.

kind regards


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