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

21–30 of 48 posts

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

#21

Post by gpderetta »

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…

Prohibiting time traveling UB in all cases is proposed by P3352 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p33...).

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

#22

Post by justneedaname »

Anyone interested in other languages that implement this should take a look at the SPARK subset of Ada. Pre and postconditions work in the same way and enforce the same behaviour described here (or at least that's what I understand it to do from a quick skim through)

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

#23

Post by smallstepforman »

For decades we have been using assert(input) and assert(output), so it's not exactly new. Forcing sanitary checks by the language runtime is an option, hence requiring contracts to spell out the range of valid input/output which is checked in debug mode. Otherwise, if it's optional, it will only be used by a subset of engineers. If its mandatory, it can cripple performance (unless we have unsafe scopes). Opt-out is always better than opt-in.

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

#24

Post by bluGill »

justneedaname wrote: post #22

Anyone interested in other languages that implement this should take a look at the SPARK subset of Ada. Pre and postconditions work in the same way and enforce the same behaviour described here (or at least that's what I understand it to do from a quick skim through)

The authors are aware of SPARK and are trying to bring that to C++.

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

#25

Post by bluGill »

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 has done a lot in C++26 around this.

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

#26

Post by johnisgood »

dataflow wrote: post #10
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…

It sounds like you're specifically talking about runtime-enforced contracts rather than ones that the compiler uses to prove compliance? Your first sentence makes it sound like you think all contracts are useless, but your last sentence makes it seem like you think they're useful if they're compile time.

Which they are (compile time) with Ada / SPARK, without any runtime costs.

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

#27

Post by rwmj »

justneedaname wrote: post #22

Anyone interested in other languages that implement this should take a look at the SPARK subset of Ada. Pre and postconditions work in the same way and enforce the same behaviour described here (or at least that's what I understand it to do from a quick skim through)

Wasn't Eiffel the first "design by contract" language? https://en.wikipedia.org/wiki/Eiffel_(programming_language)

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

#28

Post by pschanely »

fermigier wrote: post #9
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…

A reference for your dissertation? The usefulness (or lack thereof) of contracts was famously discussed in 1997 in this paper: https://www.irisa.fr/pampa/EPEE/Ariane5.html (with additional comments here: https://www.irisa.fr/pampa/EPEE/Ariane5-comments.html ). I have tried several times (a couple of decades ago) to introduce DBC in Python, using one of the many available libraries (for an overview: see https://lab.ab…

> I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases.

Agree! There is a sliding scale between testing contracts and proving them too. My labor of love for the past several years has been a tool for checking Python contracts using an SMT solver (using symbolic inputs over concrete paths): https://github.com/pschanely/CrossHair

That said, these days I think property-based testing gets you the ~same benefits as contracts, and is easier for most people to apply.

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

#29

Post by mgaunard »

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…

Contracts are widely used in the form of asserts throughout many codebases and are generally seen as improving code quality and enabling more efficient designs.

Even something like accessing an element in an array is subject to the contract that the index is less than the size.

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

#30

Post by AlotOfReading »

WalterBright wrote: post #14
fermigier wrote: post #12

Earlier quoted context omitted.

"Contract programming for C++ was implemented back in the 90's." -> Did the proposal authors contact you or refer to your work (or any other previous work)? It not, that would be a shame. "It also appears in the D programming language" -> Do people use it?

> Did the proposal authors contact you No > or refer to your work (or any other previous work)? No I presume they simply didn't know about it. I emailed the authors. > Do people use it? Yes

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...

Post reply on HN