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

On 10-10-2013 17:19, Nevin Liber wrote:

On 10 October 2013 03:54, Thorsten Ottosen 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