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

1–10 of 48 posts

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

#2

Post by pbrowne011 »

More recent revision: https://isocpp.org/files/papers/P2900R10.pdf. It seems like they've added a few things since this draft.

It's somewhat funny to hear "minimum viable product" in the context of a language standard/specification. I'd never thought of adding a feature to a language in that way before.

The idea of design by contract (DbC) in C++ appears to have been around for a while too. The authors link to a "forthcoming companion paper" (currently a 404 error), but you can find proposals from as early as 2004 with the idea: https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n16...

(and potentially earlier, I just haven't seen one yet)

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

#4

Post by discardable_dan »

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 needs to stay that way.

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

#7

Post by WalterBright »

pbrowne011 wrote: post #2

More recent revision: https://isocpp.org/files/papers/P2900R10.pdf . It seems like they've added a few things since this draft. It's somewhat funny to hear "minimum viable product" in the context of a language standard/specification. I'd never thought of adding a feature to a language in that way before. The idea of design by contract (DbC) in C++ appears to have been around for a while too. The authors link to a "fo…

You have now :-)

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

#9

Post by fermigier »

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.abilian.com/Tech/Python/DbC%20in%20Python/ ) but, like you, wasn't convinced.

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.

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

#10

Post by dataflow »

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.
Post reply on HN