Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull

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

   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf

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

"Requires:
the preconditions for calling the function"

2) Postcondition is defined like this.

"Postconditions:
the observable results established by the function."

3) 17.6.4.11 says:

"17.6.4.11 Requires paragraph [res.on.required]

Violation of the preconditions specified in a function’s
Requires:
paragraph results in undefined behavior
unless the function’s
Throws:
paragraph specifies throwing an exception when the precondition is 
violated."

So at least some people have used my terminology before.

kind regards

Thorsten