Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Contracts for C++ (DbC) [pdf]

isocpp.org

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Contracts for C++ (DbC) [pdf]

#41

Post by AlotOfReading »

rramadass wrote: post #37
mempko wrote: post #36

Earlier quoted context omitted.

Wow, people miss the point of contracts. You never want to turn them off in production, because that's where all the weird shit happens that you never thought of. Contracts catch bugs in those times. Maybe people find them useless precisely because they turn them off.

Finally, somebody said it! I am always bemused when people say they turn off contracts in production code. They don't understand the difference between contracts (a program state guarantee) and testing for special/error cases (must be handled explicitly). The excuse usually given is runtime performance which can be mitigated by using a subset from pre/post-conditions/invariants.

C++ contracts as currently designed can execute 4+ times per call to do full checking. That gets expensive quickly.

Re: Contracts for C++ (DbC) [pdf]

#42

Post by rramadass »

AlotOfReading wrote: post #41
rramadass wrote: post #37

Earlier quoted context omitted.

Finally, somebody said it! I am always bemused when people say they turn off contracts in production code. They don't understand the difference between contracts (a program state guarantee) and testing for special/error cases (must be handled explicitly). The excuse usually given is runtime performance which can be mitigated by using a subset from pre/post-conditions/invariants.

C++ contracts as currently designed can execute 4+ times per call to do full checking. That gets expensive quickly.

But they also give you 4 different evaluation semantics (ignore, observe, enforce, quick_enforce) to tweak as needed. You don't need to do full checking everywhere and always.

Re: Contracts for C++ (DbC) [pdf]

#43

Post by rramadass »

tomasGiden wrote: post #39
discardable_dan wrote: post #4

I did my dissertation work on software contracts. They are generally useless: programmers won't write them, or will write them incorrectly. Moreover, the runtime enforcement dominates all but the most-expensive functions, and contracts become an antipattern for helper functions due to their enforcement cost. Without intense compiler support and contract erasure such as David Van Horne's work, this is a dead idea that…

I worked in the telecom business 15 years ago on 4G (LTE) and there it was considered a big savior compared to how it was done before. Basically before they had a lot of error handling code and it was a significant part of the code base (don’t remember but let’s say 50%) and this error handling code had the worst quality because it is very hard to inject faults everywhere. So basically the error handling code had a l…

Nice.

Bertrand Meyer in his usual painstakingly detailed manner explains how to integrate DbC with Exception/Error handling in his paper Applying Design by Contract linked to here - https://news.ycombinator.com/item?id=42133876

Re: Contracts for C++ (DbC) [pdf]

#44

Post by int_19h »

discardable_dan wrote: post #4

I did my dissertation work on software contracts. They are generally useless: programmers won't write them, or will write them incorrectly. Moreover, the runtime enforcement dominates all but the most-expensive functions, and contracts become an antipattern for helper functions due to their enforcement cost. Without intense compiler support and contract erasure such as David Van Horne's work, this is a dead idea that…

I find it a very dubious assertion particularly with respect to performance. Well-written idiomatic code in most languages should validate inputs anyway; it's just done in an ad-hoc way - stuff like ArgumentException in .NET or ValueError etc in Python, for example. Contracts are just a way to formalize it, not only for the benefit of static analyzers, but also for better integration with existing tooling (generated docs etc).

And no, you don't have to write a code contract for every single function. Code contracts are most useful in the same exact place you'd do other kinds of contracts, like say documenting the public API of a library. From there it's diminishing gains to extend them deeper into the implementation, but in any case, one can always find a balance between performance and enforced contract checks. Not all code needs to be blazing fast, and erring on the side of correctness is preferable.

Re: Contracts for C++ (DbC) [pdf]

#45

Post by rurban »

tialaramex wrote: post #17

Assuming that this or something substantially identical does land for C++ 26 I think we should start betting on when SG23 (the committee's Study Group for "Safety and Security") is replaced by some hypothetical SG24 "Safety and Security No But Really". We already know that because C++ Undefined Behaviour can cause what are called "Time Travel" defects and this paper doesn't do anything to prevent it, adding contracts…

SG23 is already the Safety and Security No But Really group. Multiple safety proposals were already ignored for C++26

Re: Contracts for C++ (DbC) [pdf]

#46

Post by JimBright »

WalterBright wrote: post #40
AlotOfReading wrote: post #30

Earlier quoted context omitted.

I'd assume the authors were aware of it, given that the original set of proposals from 2004-2006 directly compares facilities in D and Eiffel. Plus, you know, andrei. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n19...

I had missed this, the paper does mention D: "Programming languages such as Eiffel and D have a Contracts facility; this paper proposes a Contracts facility for C++."

Maybe you should execute their trainer!

Re: Contracts for C++ (DbC) [pdf]

#47

Post by mempko »

rramadass wrote: post #37
mempko wrote: post #36

Earlier quoted context omitted.

Wow, people miss the point of contracts. You never want to turn them off in production, because that's where all the weird shit happens that you never thought of. Contracts catch bugs in those times. Maybe people find them useless precisely because they turn them off.

Finally, somebody said it! I am always bemused when people say they turn off contracts in production code. They don't understand the difference between contracts (a program state guarantee) and testing for special/error cases (must be handled explicitly). The excuse usually given is runtime performance which can be mitigated by using a subset from pre/post-conditions/invariants.

Exactly. What I do is litter my code with contracts. I then profile to find the hot loop and minimize (not turn them off) there. For the 99% of the other code, the user won't notice any slowdown.

The value is just too high to turn them off in production. Do you want bug free code? This is the only way I know how to do it.

Post reply on HN