You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+27-9Lines changed: 27 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,7 +30,7 @@ When the `ASSERTIONS` preprocessor macro is not defined to any value,
30
30
the default is that assertions are *disabled* and will not check the condition.
31
31
32
32
To enable assertion enforcement (e.g., for a debug build), define the
33
-
preprocessor ASSERTIONS to non-zero, eg:
33
+
preprocessor ASSERTIONS to non-zero, e.g.,
34
34
```
35
35
fpm build --flag "-DASSERTIONS"
36
36
```
@@ -45,10 +45,27 @@ Use Cases
45
45
---------
46
46
Two common use cases include
47
47
48
-
1.[Enforcing programming contracts] throughout a project via runtime checks.
49
-
2.Producing output in `pure` procedures for debugging purposes.
48
+
1.[Producing output in pure procedures] for debugging purposes.
49
+
2.[Enforcing programming contracts] throughout a project via runtime checks.
50
50
51
-
### Enforcing programming contracts
51
+
### Producing output in pure procedures
52
+
Writing pure procedures communicates useful information to a compiler or a developer.
53
+
Specifically, the pure attribute conveys compliance with several constraints that clarify data dependencies and preclude side effects.
54
+
For a compiler, these constraints support optimizations, including automatic parallelization on a central processing unit (CPU) or offloading to a graphics processing unit (GPU).
55
+
For a developer, the constraints support refactoring tasks such as code movement.
56
+
57
+
A developer seeking output inside a procedure presumably has an expectation regarding what ranges of output values represent correct program execution.
58
+
A developer can state such expectations in an assertion such as `call_assert(i>0 .and. j<0)`.
59
+
Enforce the assertion by defining the `ASSERTIONS` macro when compiling.
60
+
If the expectation is not met, the program error terminates and prints a stop code showing the assertion's file and line location and a description.
61
+
By default, the description is the literal text of what was asserted: `i>0 .and. j<0` in the aforementioned example.
62
+
Alternatively, the user can provide a custom description.
63
+
64
+
For richer diagnostic messages from failed assertions, please see the [Julienne] correctness-checking framework.
65
+
Julienne wraps Assert and defines idioms that automatically generate diagnostic messages containing program data.
66
+
Julienne also offers string-handling utilities to assist users with customizing diagnostic messages by, for example, converting an array of numeric type into string representing comma-separated values as text.
67
+
68
+
## Enforcing programming contracts
52
69
Programming can be thought of as requirements for correct execution of a procedure and assurances for the result of correct execution.
53
70
The requirements and assurances might be constraints of three kinds:
54
71
@@ -193,17 +210,17 @@ limit. This can result in compile-time errors like the following from gfortran:
193
210
Error: Line truncated at (1) [-Werror=line-truncation]
194
211
```
195
212
196
-
Some compilers offer a command-line argument that can be used to workaround this legacy limit, eg:
213
+
Some compilers offer a command-line argument that can be used to workaround this legacy limit, e.g.,
0 commit comments