The precondition states that at function entry the argument `x` must be strictly smaller than the maximum allowable value of its type (so it can be incremented by `1` without overflowing).
The postcondition states that at function exit the argument `x` must be incremented by `1` with respect to the /old value/ that `x` had before executing the function (indicated here by [^['oldof]]`(x)`).
-Note that postconditions shall be checked only when the execution of the function body did not throw an exception.
+Note that postconditions shall be checked only when the execution of the function body does not throw an exception.
Now let's program this function and its contract using this library (see [@../../example/features/introduction.cpp =introduction.cpp=] and __Non_Member_Functions__):
Instead, if there is a bug in the implementation of `inc` so that `x` is not incremented by `1` after the execution of the function body then the program will terminate with an error message similar to the following (and it will be evident that the bug is in `inc` body):
[footnote
In this example the function body is composed of a single trivial instruction `++x` so it easy to check by visual inspection that it does not contain any bug and it will always increment `x` by `1` thus the function postcondition will never fail.
-In real code, function bodies are rarely this simple and can hide bugs which makes checking postconditions useful.
+In real production code, function bodies are rarely this simple and can hide bugs which make checking postconditions useful.
]
[pre
]
[note
-C++11 lambda functions are necessary to use this library without manually writing a significant amount of boiler-plate code to program the functors that assert the contracts (see __No_Lambda_Functions__).
+C++11 lambda functions are necessary to use this library without manually writing a significant amount of boiler-plate code to program functors that assert the contracts (see __No_Lambda_Functions__).
That said, this library implementation does not use C++11 features and should work on most modern C++ compilers (see __Getting_Started__).
]
In addition to contracts for non-member functions as shown the in the example above, this library allows to program contracts for constructors, destructors, and member functions.
These can check class invariants and can also /subcontract/ inheriting and extending contracts from base classes (see [@../../example/features/introduction_public.cpp =introduction_public.cpp=] and __Public_Function_Overrides__):
[footnote
-The `pushable` base class is used in this example just to show subcontracting, it is somewhat arbitrary and it will likely not appear in real code.
+The `pushable` base class is used in this example just to show subcontracting, it is somewhat arbitrary and it will likely not appear in real production code.
]
[import ../example/features/introduction_public.cpp]
The authors of this library advocate for contracts to be added to the core language.
Adding contract programming to the C++ standard has a number of advantages over any library implementation (shorter and more concise syntax to program contracts, specify contracts in declarations instead of definitions, enforce contract constant-correctness, expected faster compile- and run-time, vendors could develop static analysis tools to recognize and check contracts statically when possible, compiler optimizations could be improved based on contract conditions, etc.).
-Unfortunately, detailed and complete proposals to add contracts to the C++ standard such as __N1962__ were rejected by the C++ standard committee and it is not clear if the current proposal for adding contracts to C++ __P0380__ will actually be accepted by the standard.
-[footnote
-The authors find attractive the syntax that uses C++11 attributes `[[...]]` to specify contracts as indicated in __P0380__.
-]
-In any case, at least for now __P0380__ only supports pre- and postconditions while missing basic features such as class invariants and old values in postconditions, not to mention the lack of more advanced features like subcontracting.
-All these features are instead supported by this library (see __Feature_Summary__ for a detailed comparison between the features supported by this library and the ones listed in different contract programming proposals, see __Bibliography__ for a list of references considered during the design and implementation of this library, including the vast majority of contract programming proposals submitted to the C++ standard committee).
+The __P0380__ proposal supports basic contract programming, it was accepted and it will be included in C++20.
+This is undoubtedly a step in the right direction, but unfortunately __P0380__ only supports pre- and postconditions while missing important features such as class invariants and old values in postconditions, not to mention the lack of more advanced features like subcontracting (more complete proposals like __N1962__ were rejected by the C++ standard committee).
+All contracting programming features are instead supported by this library (see __Feature_Summary__ for a detailed comparison between the features supported by this library and the ones listed in different contract programming proposals, see __Bibliography__ for a list of references considered during the design and implementation of this library, including the vast majority of contract programming proposals submitted to the C++ standard committee).
[endsect]
projects / platform / upstream / boost.git / blobdiff