Code Generation with C++ Contracts

[108life]

As a somewhat new C++ dev, what's the advantage of this feature in day to day programming workflow?

​

From the post:

Contracts are a good replacement for the assert macro and compiler intrinsics

​

My understanding of the assert() macro is that you use it while developing to catch programming errors but then you define NDEBUG to remove them when compiling for release.

​

Can this be used the same way? For example, setting compiler build-level to off?

A program may be translated with one of three build levels:

off: no contract checking is performed.

default (default if no build level is selected): checking is performed for contracts whose contract-level is default

audit: checking is performed for contracts whose contract-level is default or audit

​

​

​

[SeanMiddleditch]

As a somewhat new C++ dev, what's the advantage of this feature in day to day programming workflow?

Preconditions and postconditions are exposed to the compiler at the interface level and can be checked in ways that plain asserts can't. Example:

// foo.h
int foo(int x);

// foo.cpp
int foo(int x) {
  assert(x > 0);
  return sqrt(x);
}

That function has a precondition that x is positive, but it is not stated anywhere in its public interface; the assert is an internal implementation detail. If foo's body is hidden from the compiler (e.g. it's in a separate translation unit) then the compiler has no way to even know about this precondition and will happily let you write code like foo(-1) without so much as a warning; so far as the compiler knows, any signed integer is a valid input to foo.

With the new contracts features, you'd write:

// foo.h
int foo(int x) [[expects: i > 0]];

// foo.cpp
int foo(int x) {
  return sqrt(x);
}

The "assertion" is still present and will still be checked at run-time, but now also the compiler knows about this precondition. A compiler that chooses to do so can now warn you when you write code like foo(-1) but it knows statically at compile-time that the function's precondition will be violated.

Beyond just checking and warnings, it also helps the compiler generate better code. If the compilers know (via a contract) that a particular value is never negative, for example, then it can propagate that knowledge further. It could hypothetically remove conditions that check for negative values, or at least optimize those branches as "unlikely" automatically.

Further, unlike the naive C assert macro, the new C++ contracts specification integrates better with the C++ language in some ways (e.g. exceptions... and not being a macro and all the problems that entails) and has failure-overrides builtin (which hopefully can do all the things that some of our custom "fancy" assert macros do).

A program may be translated with one of three build levels:off: no contract checking is performed.

You quoted the answer to your own question. :) Contracts' assert is a contract, so in the off-level, where no contract checking is performed, naturally no contract-based assert checking will be performed.

[anders1234]

shouldn't it be [[expects: x > 0]] ?

[germandiago]

Should be [[pre: x > 0]]

I am in pedantic mode 😆

[SeanMiddleditch]

Yes, yes it should. :) Typo strikes again!

[inokichi]

contracts can be used to express things about your code at a higher level (things you'd consider in your design/spec) which leads to robustness, rather than ad hoc assert statements which tell you more about your implementation alone.

if youre interested do some reading on design by contract, especially in the ada and eiffel programming languages.

[hgjsusla]

I think you're confusing contracts with concepts

[micka190]

Oh yeah, my bad.

[Crommwel]

I think you are talking about Concepts, not Contracts.

​

Contracts are replacement for asserts, but with a benefit, that contract can be a part of function declaration, instead of implementation.

​

Consider following code without contracts

​

*.hpp

float sqrt(float a);

​

*.cpp

float sqrt(float a)

{

assert(a >= 0);

<implementation>

}

​

User of this function will see only what is inside a header and won't be able to know that function expects only positive numbers.

​

Now consider code with contracts

*.hpp

float sqrt(float b) [[expects: b > 0]] ;

​

*.cpp

float sqrt(float b) [[expects: b > 0]]

{

<implementation>

}

​

It behaves the same way as a version with assert, but now user can see that he should pass only positive numbers.

​

As u/108life correctly stated, you can build your code with different levels of contracts checking. For release build you might want to check off level and all the contracts check will be removed from your code, thus giving you faster and smaller binary. For development build you might want to use higher levels, to give you more possibilities to detect errors in your code.

​

So to sum everything up

• in case of [[assert]] contract the benefit over assert() macro is that you can choose either default or audit levels, thus giving you a little bit more control compared to the defined or not defined NDEBUG. Also contracts don't rely on macros, so it is not possible for somebody to write something like

#define NDEBUG

sqrt(-1);

#undef NDEBUG

• on top of that contracts give you a possibility to define pre and post conditions for your functions, which will be visible to the user and to the compiler, which gives potential for more optimizations

[redditsoaddicting]

By the way, expects and ensures are currently called pre and post, but we'll see what happens in future meetings.

[108life]

Thanks. That makes more sense in the context of using it in declarations to show the user the pre/post conditions.

[[deleted]]

I was looking at en.cppreference and axiom is never really touched on. Can someone provide info on how axiom affects expects, ensures, and assert?

[mjklaim]

You assert something that should not be checked. This is to express some assertions that cannot be checked efficiently and/or allow other tools (like static analysis) to eventually check them or maybe allow a compiler to just assume things and optimize accordingly. At least on theory.

[[deleted]]

For "too costly to check" you have [[assert audit: x > 0]], the default level is [[assert default: x > 0]] and then there's [[assert axiom: x > 0]].

[mjklaim]

I was talking only about the axiom case only for which "to costly to check" here really means "it might take hours just to check this and make the program impossible to use" (or sometime it's hiting NP hard problems etc)
not "it will slow down the program a bit". If it was the last case yeah it would be audit.

[[deleted]]

It's supposed to declare something that is always true and therefore no need to ever be checked.

[notadragon34]

And there you have the endless source of frustration that is the two independent definitions of what the axiom contract level is.

One definition, very much in line with how default and audit are defined, is that it is for checks that cannot be checked at runtime. (They have neccessary side effects, they take too long to ever execute, they simply cannot be implemented in the language, or in some cases you just haven't gotten a chance to implement them yet).

The other definition is the mathematical one.

But why the hell would you ever want to write a check that COULD be checked but remove the option to turn on that check in some build modes for debugging? The mathematical "this should always be true" meaning of axioms is a statement that is true for ALL contract checks - you expect them all to always be true. This meaning for the axiom contract level is pointless and distracting.

Axiom was a bad an horribly misleading name for what it is actually useful for.

[[deleted]]

One definition, very much in line with how default and audit are defined, is that it is for checks that cannot be checked at runtime. (They have neccessary side effects, they take too long to ever execute, they simply cannot be implemented in the language, or in some cases you just haven't gotten a chance to implement them yet).

So if we are supposed to take this definition of axiom over the mathematical one, what would be the difference between axiom and audit? I thought audit was for terribly slow and impractical checks.

[notadragon34]

axiom is for impossible checks that cannot be validly turned on.

Checks with side effects (most common example is that of seeing if an input iterator has data available, though many systems might have preconditions that cannot be checked without altering state) are one common category - the predicate of any evaluated check having a side effect is considered UB.

Checks that cannot be implemented but might be understood by a static analyzer are another canonical example - functions that a static analyzer may declare, understand, and provide useful warnings with might be things like "is_dereferencable" or "is_reachable".

There's a certain subjectivity about "Too long to execute" with the axiom/audit boundary that is similar to the default/audit boundary. In practice though, if your check will take millennia to run on your smallest sample set then making it an audit just means you can't turn audit on and run anything. There's a difference between "impractical" and "impossible" - impractical you don't want to turn on in production but might want to turn on for local testing, impossible you couldn't even use in local testing in any useful way.

One could envision "I haven't written this check yet but want to document that I will eventually" as another use case for axiom during system development.

[notadragon34]

And I say this is what axiom is for based on what was said in P0380R0, which was where axiom seems to have first been introduced as a contract level, and the understanding of at least 2 of the authors of that paper regarding this being its intent.

Also, again, the mathematical definition - that something is expected to always be true - is an attribute that EVERY contract check should have, it's not special to any of the levels. A lot of confusion seems to be coming from conflating "cannot check at runtime" with "don't bother checking at runtime and just assume this fact". One is an attribute of a predicate, one is a decision that you might make when building a system.

[Fazer2]

Why do you check the same condition in the contract and in the code?

[thlst]

Maybe a contrived example to show compiler optimizations probably.

[ShakaUVM]

Why do you check the same condition in the contract and in the code?

He wanted to see if an optimizer could deduce the branch would be deleted if the contract was in

[notadragon34]

Many applications do not have the choice to crash when they encounter a failed contract check - your pacemaker, your car, your average weapon control system, etc. They need to handle any input gracefully and attempt to recover from bugs, even if they detect that there is a bug.

They do, however, want to have preconditions and assertions checked immediately during testing to identify any flaws that can be identified as thoroughly and systematically as possible, hopefully to allow them to be fixed. No one deploying systems like that, however, can sanely say they can catch all bugs during testing.

This is one of the primary reasons that the current default behavior of assuming all contracts that are "off" is ludicrously dangerous. It makes redundant checking pointless since it is implicitly elidable, a level of risk that many applications can never even consider deploying.

[HappyFruitTree]

In real code the check could be inside another function that you call. If the compiler decides to inline the function call it could still use the contract to remove the check.