renamed smoke tests, added extras section to docs
This commit is contained in:
Lorenzo Caminiti
parent
d8afc9bb39
commit
2dc0038b14
@ -162,102 +162,6 @@ The [macroref BOOST_CONTRACT_NAMED_OVERRIDE] macro can be used for function name
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Move Operations]
|
||||
|
||||
As with all public operations of a class, also move operations should maintain class invariants (see also __Stroustrup13__, p. 520).
|
||||
Specifically, C++ requires the following:
|
||||
|
||||
* The moved-from object can be copy assigned.
|
||||
* The moved-from object can be move assigned.
|
||||
* The moved-from object can be destroyed.
|
||||
[footnote
|
||||
If not anything else, this requires that class invariants are maintained by move operations because the destructor of the moved-from object requires that class invariants are true at its entry (as always with destructors, see also __Destructor_Calls__).
|
||||
]
|
||||
|
||||
Thus both the move constructor and the move assignment operator need to maintain the class invariants of the moved-from object and their contracts can be programmed using [funcref boost::contract::constructor] and [funcref boost::contract::public_function] as always for constructors and public member functions, for example (see also [@../../example/features/move.cpp =move.cpp=]):
|
||||
|
||||
[import ../example/features/move.cpp]
|
||||
[move]
|
||||
|
||||
This example assumes that it is possible to call the public member function `move()` on the moved-from object.
|
||||
This allows to make explicit the precondition that except for destructor, copy and move assignments all other public member functions cannot be called on a moved-from object.
|
||||
This precondition is usually implicit in C++ (i.e., documented by the standard but not checked by the language at run-time).
|
||||
If it is is not possible (e.g., due to some optimized implementation of the move operations) to have such a public `move()` member function, the private `moved_` member (or similar) can be used to program class invariants and preconditions (and that will just relay on the usual implicit C++ assumption on moved-from object because users will not be able to fully check preconditions and class invariants before calling functions of a moved-from object).
|
||||
|
||||
[note
|
||||
The default move constructor and move assignment operator automatically generated by C++ will not check contracts.
|
||||
Therefore, unless these operations are not public or they have no preconditions, no postconditions, and the class has no invariants, programmers should manually define them using [funcref boost::contract::constructor], [classref boost::contract::constructor_precondition], and [funcref boost::contract::public_function].
|
||||
(Same for all other automatically generated operations.)
|
||||
]
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Unions]
|
||||
|
||||
In C++, a `union` cannot have virtual member functions, bases classes, and cannot be used as a base class thus subcontracting ([classref boost::contract::virtual_], [macroref BOOST_CONTRACT_OVERRIDE], etc.) do not apply to unions.
|
||||
Also a `union` cannot inherit from [classref boost::contract::constructor_precondition] (because it cannot have base classes) so such a class is used to declare a local object that checks constructor preconditions (see `pre` in the example below).
|
||||
A part from that, this library is used as usual to program contracts for unions, for example (see also [@../../example/features/union.cpp =union.cpp=]):
|
||||
|
||||
[import ../example/features/union.cpp]
|
||||
[union]
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Volatile Class Invariants]
|
||||
|
||||
This library allows to specify a different set of class invariants to be checked for public volatile member functions.
|
||||
These /volatile class invariants/ are programmed in a public member function `const volatile` qualified and named `invariant` (see [macroref BOOST_CONTRACT_INVARIANT] to name the invariant function differently from `invariant` and __Access__ to not have to declare it public).
|
||||
|
||||
In general, `const volatile` qualified invariants work the same as `const` qualified invariant (see __Class_Invariants__) with the only difference that `volatile` and `const volatile` member functions check `const volatile` invariants while mutable (i.e., neither `const` nor `volatile` qualified) and `const` member functions check `const` invariants.
|
||||
A given class can specify both `const volatile` and `const` qualified invariant member functions:
|
||||
[footnote
|
||||
*Rationale:*
|
||||
Constructors and destructors check `const volatile` and `const` invariants in that order because the qualifier that limits the calls the least is checked first (note that a `const volatile` calls can be made on any object while `const` calls cannot be made on `volatile` non-`const` objects, in that sense the `const volatile` qualifier limits calls on an object less than `const` alone does).
|
||||
This is consistent with `static` class invariants that are checked even before `const volatile` invariants (the `static` classifier limits calls even less than `const volatile` in the sense that an object is not even needed to make static calls).
|
||||
While there is a more important reason to check `static` invariants before all other invariants (see __Contract_Programming_Overview__), the above is the only reason why this library checks `const volatile` invariants before `const` invariants for constructors and destructors.
|
||||
]
|
||||
|
||||
* Constructors check both `const volatile` and `const` qualified invariants in that order (at exit if no exception is thrown).
|
||||
* Destructors check both `const volatile` and `const` qualified invariants (at entry).
|
||||
* Both mutable and `const` public member functions check `const` qualified invariants (at entry and at exit if no exception is thrown).
|
||||
* Both `volatile` and `const volatile` public member functions check `const volatile` qualified invariants (at entry and at exit if no exception is thrown).
|
||||
|
||||
This ensures that volatile class invariants are correctly checked (see also __Constructor_Calls__, __Destructor_Calls__, and __Public_Function_Calls__).
|
||||
For example (see also [@../../example/features/volatile.cpp =volatile.cpp=]):
|
||||
|
||||
[import ../example/features/volatile.cpp]
|
||||
[volatile]
|
||||
|
||||
While this library does not automatically check `const volatile` invariants for non-volatile functions, programmers can explicitly call the `const volatile` invariant function from the `const` invariant function if that makes sense for the contracts being specified (that way all public member functions `volatile` and not will check `const volatile` invariants):
|
||||
[footnote
|
||||
*Rationale:*
|
||||
Note that while all public member functions can be made to check `const volatile` invariants, it is never possible to make volatile public member functions check `const` non-volatile invariants.
|
||||
That is because both `const` and `volatile` can always be added but never stripped in C++ (a part from forcefully via `const_cast`) but `const` is always automatically added by this library in order to enforce contract constant-correctness (see __Constant_Correctness__).
|
||||
That said, it would be incorrect for this library to also automatically add `volatile` and require all functions to check `const volatile` (not just `const`) invariants because only `volatile` members can be accessed from `const volatile` invariants so there could be many `const` (but not `const volatile`) members that are accessible from `const` invariants but not from `const volatile` invariants.
|
||||
To avoid this confusion, this library has chosen to draw a clear dichotomy between `const` and `const volatile` invariants so that only volatile members check `const volatile` invariants and only non-volatile members check `const` (but not `const volatile`) invariants.
|
||||
This is simple and should serve most cases.
|
||||
If programmers need non-volatile members to check `const volatile` invariants, they can explicitly do so by calling the `const volatile` invariant function from the `const` invariant function as shown in this documentation.
|
||||
]
|
||||
|
||||
class ``[^['class-type]]`` {
|
||||
public:
|
||||
void invariant() const {
|
||||
``[^['class-type]]`` const volatile& cv = *this;
|
||||
cv.invariant(); // Call `void invariant() const volatile` below.
|
||||
...
|
||||
}
|
||||
|
||||
void invariant() const volatile {
|
||||
...
|
||||
}
|
||||
|
||||
...
|
||||
};
|
||||
|
||||
As usual, static class invariants can also be specified (see __Static_Class_Invariants__) and private and protected member functions do not check any invariant (see __Private_and_Protected_Functions__).
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Old Values at Body]
|
||||
|
||||
In the examples seen so far old value variables of type [classref boost::contract::old_ptr] are initialized to a copy of the expression passed to [macroref BOOST_CONTRACT_OLDOF] at the point of their declaration.
|
||||
@ -449,44 +353,6 @@ This technique is not used in most examples of this documentation only for brevi
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Separate Body Implementation]
|
||||
|
||||
Contracts are part of the program specification and not of its implementation (see also __Specification_and_Implementation__).
|
||||
However, this library uses function definitions to program the contracts so contract code appears together with the function implementation code.
|
||||
This is not ideal, but contract code programmed with this library must always appear at the very top of the function definition so programmers will easily be able to distinguish it from the rest of function implementation code (so this might not be real problem in practise).
|
||||
|
||||
In some cases, it might be desirable to completely separate the contract code (function specification) from the function body code (function implementation).
|
||||
For example, this could be necessary for software that ships only header files and pre-compiled source code to its users (notably, that cannot be done for template code in C++).
|
||||
If the contracts are programmed in the function definitions that are pre-compiled with the source code, users will not be able to inspect the contract code to understand semantics and usage of the functions (again, this might not be a real problem in practice for example if contract code is already somehow extracted from the source code and presented as part of the documentation of the shipped software).
|
||||
|
||||
In such cases, the function implementation can be programmed in an extra /body function/ (e.g., named `..._body`) that is defined in the source code.
|
||||
The original function definition remains in the header files instead, it programs the contract and simply calls the extra body function.
|
||||
At the cost of programmers writing an extra function declaration for the body function, this technique allows to keep the contract code in header files while separating the body implementation code to source files (with the limitation that constructor member initialization lists must still be programmed in the header files because that is where the constructors are actually defined).
|
||||
|
||||
For example, the following header file only contains function declarations and contract code (function specifications) and constructor member initializations (see also [@../../example/features/separate_body.hpp =separate_body.hpp=]):
|
||||
|
||||
[import ../example/features/separate_body.hpp]
|
||||
[separate_body_hpp]
|
||||
|
||||
Instead, the function bodies (function implementations) is programmed in a separate source file (see also [@../../example/features/separate_body.cpp =separate_body.cpp=]):
|
||||
|
||||
[import ../example/features/separate_body.cpp]
|
||||
[separate_body_cpp]
|
||||
|
||||
The same technique can be used for non-member, private, and protected functions.
|
||||
|
||||
[note
|
||||
When contracts are programmed in a separate =.cpp= files and also /all/ these library headers are `#include`d only from =.cpp= files, then the =.cpp= files can be compiled disabling specific contract checking (for example, [macroref BOOST_CONTRACT_NO_POSTCONDITIONS] and [macroref BOOST_CONTRACT_NO_EXIT_INVARIANTS], see __Disable_Contract_Checking__).
|
||||
The user code that will link to these =.cpp= files not be able to
|
||||
Then the code in these =.cpp= files will always have such contract checking disabled even when linked to some other user code that might have been compiled with a different set of disable contracts (i.e., a different `BOOST_CONTRACT_NO_...` defined).
|
||||
This technique might be useful to ship a pre-compiled set of object files (e.g., for a library) that will never check some contracts (e.g., postconditions and exit invariants) regardless of the definition of the `BOOST_CONTRACT_NO_...` macros used to compile code that uses such object files.
|
||||
|
||||
On the contrary, if contracts are programmed in header files and this library headers are `#include`d in header files that are being shipped, then end users enable or disables contracts of the shipped code by defining `BOOST_CONTRACT_NO_...` when they compiled the shipped header files as part of their code.
|
||||
This technique might be useful in other situations when programmers that ship code want instead to leave it up the their end users to decide which contracts in the shipped code should be checked at run-time.
|
||||
]
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Throw on Failure]
|
||||
|
||||
If a condition checked using [macroref BOOST_CONTRACT_ASSERT] is `false` or if code specified in preconditions, postconditions, and class invariants throws an exception, this library calls the /contract failure handler/ functions [funcref boost::contract::precondition_failure], [funcref boost::contract::postcondition_failure], [funcref boost::contract::entry_invariant_failure], or [funcref boost::contract::exit_invariant_failure] respectively (in fact, [macroref BOOST_CONTRACT_ASSERT] simply expands to code that throws a [classref boost::contract::assertion_failure] exception, see also __No_Macros__).
|
||||
@ -532,149 +398,5 @@ For example, programmers could decide to check all contracts during early develo
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Disable Contract Compilation]
|
||||
|
||||
This library provides macros that can be used to disable compile-time overhead introduced by contracts but at the cost of manually programming `#ifdef` statements around contract code.
|
||||
The authors of this library do not recommend to use this practice unless strictly necessary because it makes the contract code more verbose, less readable, and in most applications the compile-time overhead of contracts should not represent an issue (it should be sufficient to disable contract checking at run-time as indicated before).
|
||||
|
||||
In any case, the following example illustrates how to completely disable contract code compilation for non-member functions (see also [@../../example/features/ifdef.cpp =ifdef.cpp=]):
|
||||
|
||||
[import ../example/features/ifdef.cpp]
|
||||
[ifdef_function]
|
||||
|
||||
The same is done to disable contract code complication for private and protected functions.
|
||||
For constructors, destructors, and public functions instead (see also [@../../example/features/ifdef.cpp =ifdef.cpp=]):
|
||||
|
||||
[ifdef_class]
|
||||
|
||||
As shown by the examples above:
|
||||
|
||||
* The [macroref BOOST_CONTRACT_NO_PRECONDITIONS] macro is defined by programmers and it can be used in `#ifdef` statements to disable compilation of preconditions, including constructor preconditions ([classref boost::contract::constructor_precondition]).
|
||||
* The [macroref BOOST_CONTRACT_NO_POSTCONDITIONS] macro is defined by programmers and it can be used in `#ifdef` statements to disable compilation of postconditions, old value declarations, and old value assignments at body (`.old(...)`).
|
||||
* The [macroref BOOST_CONTRACT_NO_INVARIANTS] macro is defined by programmers (or it will be automatically defined by this library if both [macroref BOOST_CONTRACT_NO_ENTRY_INVARIANTS] and [macroref BOOST_CONTRACT_NO_EXIT_INVARIANTS] are defined) and it can be used in `#ifdef` statements to disable compilation of class invariants (including static and volatile class invariants).
|
||||
Also the [macroref BOOST_CONTRACT_NO_ENTRY_INVARIANTS] and [macroref BOOST_CONTRACT_NO_EXIT_INVARIANTS] macros are defined by programmers (or they will be both automatically defined by this library if [macroref BOOST_CONTRACT_NO_INVARIANTS] is defined) but these macros are not directly used to disable contract code compilation (only contract code run-time checking).
|
||||
* The [macroref BOOST_CONTRACT_NO_CONSTRUCTORS] macro is automatically defined by this library (a compile-time error will be reported if programmes try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of constructor contract guards.
|
||||
* The [macroref BOOST_CONTRACT_NO_DESTRUCTORS] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of destructor contract guards.
|
||||
* The [macroref BOOST_CONTRACT_NO_PUBLIC_FUNCTIONS] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of public member function contract guards, base type `typedef`, extra [classref boost::contract::virtual_] function parameters, and [macroref BOOST_CONTRACT_OVERRIDE] declarations.
|
||||
* The [macroref BOOST_CONTRACT_NO_FUNCTIONS] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of contract guards for non-member functions as well as private and protected functions.
|
||||
* The [macroref BOOST_CONTRACT_NO_ALL] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable [classref boost::contract::access] friendship declarations and also inclusions of [headerref boost/contract.hpp] (some of the other macros listed here can be used to selectively disable inclusion of =boost/contract/*.hpp= headers when they are used instead of [headerref boost/contract.hpp].)
|
||||
|
||||
[endsect]
|
||||
|
||||
[section No Macros (No C++11)]
|
||||
|
||||
It is possible to specify contracts without using this library macros and programming the related code manually instead (a part from [macroref BOOST_CONTRACT_OVERRIDE], [macroref BOOST_CONTRACT_OVERRIDES], and [macroref BOOST_CONTRACT_NAMED_OVERRIDE] that cannot be programmed manually).
|
||||
|
||||
Some of this library macros are variadic macros, others are not (see below).
|
||||
Variadic macros were officially added to the language since C++11 but most compilers have been supporting variadic macros as an extension for a long time, plus essentially all compilers that support C++11 lambda functions also support C++11 variadic macros (and this library might rarely be used without the convenience of C++11 lambda functions, see also __No_Lambda_Functions__).
|
||||
Therefore, the following can be considered mainly a curiosity because programmers should seldom need to use this library without using its macros.
|
||||
|
||||
[heading Overrides]
|
||||
|
||||
As shown in __Public_Function_Overrides__ and __Named_Overrides__, this library provides the [macroref BOOST_CONTRACT_OVERRIDE] and [macroref BOOST_CONTRACT_NAMED_OVERRIDE] macros to program contracts for overriding public functions.
|
||||
These macros cannot be programmed manually but they are not variadic macros so programmers should be able to use them on all C++ compilers.
|
||||
[footnote
|
||||
*Rationale:*
|
||||
These macros expand SFINAE-based introspection templates that cannot be reasonably programmed by users (that remains the case even if C++14 generic lambdas were to be used here).
|
||||
]
|
||||
The [macroref BOOST_CONTRACT_OVERRIDES] macro is a variadic macro instead but programmes can manually repeat the non-variadic macro [macroref BOOST_CONTRACT_OVERRIDE] for each overriding public function name on compilers that do not support variadic macros.
|
||||
|
||||
[heading Assertions (Not Variadic)]
|
||||
|
||||
As shown in __Preconditions__, __Postconditions__, __Class_Invariants__, etc. this library provides the [macroref BOOST_CONTRACT_ASSERT] macro to assert contract conditions.
|
||||
This is not a variadic macro and programmers should be able to use it on all C++ compilers.
|
||||
However, the macro invocation `BOOST_CONTRACT_ASSERT(`[^['condition]]`)` simply expands to code equivalent to the following:
|
||||
|
||||
if(!``[^['condition]]``) {
|
||||
throw boost::contract::assertion_failure(__FILE__, __LINE__,
|
||||
BOOST_PP_STRINGIZE(``[^['condition]]``));
|
||||
}
|
||||
|
||||
That is because this library considers any exception thrown from within preconditions, postconditions, and class invariants as a contract failure and reports it calling the related contract failure handler ([funcref boost::contract::precondition_failure], etc., see also __Throw_on_Failure__).
|
||||
In fact, if there is a need for it, programmers can always program contract assertions that throw an exception as follow (see [@../../example/features/throw_on_failure.cpp =throw_on_failure.cpp=] for an example):
|
||||
|
||||
if(!``[^['condition]]``) throw ``[^['exception-type]]``(...);
|
||||
|
||||
However, using [macroref BOOST_CONTRACT_ASSERT] always allows this library to show detailed information about the assertion code, its file and line number, etc.
|
||||
|
||||
[heading Base Types (Variadic)]
|
||||
|
||||
As shown in __Base_Classes__, this library provides the [macroref BOOST_CONTRACT_BASE_TYPES] variadic macro to declare the `base_types` member type that lists all public bases of a derived class.
|
||||
Programmers can also declare `base_types` without using [macroref BOOST_CONTRACT_BASE_TYPES] at the cost of writing a bit more code manually, for example (see also [@../../example/features/base_types_no_macros.cpp =base_types_no_macros.cpp=]):
|
||||
|
||||
[import ../example/features/base_types_no_macros.cpp]
|
||||
[base_types_no_macros]
|
||||
|
||||
The `base_types` member type must be a `boost::mpl::vector` and it must list /only/ `public` base classes (because only public bases subcontract, see also __Function_Calls__).
|
||||
If the [macroref BOOST_CONTRACT_BASE_TYPES] macro is not used, it is the responsibility of the programmers to maintain the correct list of bases in the `boost::mpl::vector` each time the derived class inheritance list changes (this might complicate maintenance).
|
||||
In general, it is recommended to use the [macroref BOOST_CONTRACT_BASE_TYPES] macro if possible.
|
||||
|
||||
[heading Old Values (Variadic)]
|
||||
|
||||
As shown in __Old_Values__, this library provides the [macroref BOOST_CONTRACT_OLDOF] variadic macro to assign old value copies.
|
||||
Programmers can also assign old values without using [macroref BOOST_CONTRACT_OLDOF] at the cost of writing a bit more code manually, for example (see also [@../../example/features/old_no_macros.cpp =old_no_macros.cpp=]):
|
||||
|
||||
[import ../example/features/old_no_macros.cpp]
|
||||
[old_no_macros]
|
||||
|
||||
The ternary operator `boost::contract::copy_old(v) ? size() : boost::contract::null_old()` must be used here to avoid evaluating and copying the old value expression `size()` when [funcref boost::contract::copy_old] returns `false` because old values are not being copied (postcondition checking is disable at run-time, an overridden virtual function call is not checking postconditions yet, etc.).
|
||||
The enclosing [funcref boost::contract::make_old] copies the old value expression and creates an old value pointer, while [funcref boost::contract::null_old] indicates when a null old value pointer should be created.
|
||||
|
||||
The [funcref boost::contract::make_old] and [funcref boost::contract::copy_old] functions are used exactly as above but without the extra `v` parameter when they are called from within non-virtual functions (see also __Public_Function_Overrides__).
|
||||
The old value pointer returned by [funcref boost::contract::make_old] can be assigned to either [classref boost::contract::old_ptr] or [classref boost::contract::noncoyable_old_ptr] (see also __Old_Value_Requirements__).
|
||||
|
||||
In general, it is recommended to use the [macroref BOOST_CONTRACT_OLDOF] macro if possible.
|
||||
|
||||
[endsect]
|
||||
|
||||
[section No Lambda Functions (No C++11)]
|
||||
|
||||
This section shows how to use this library without C++11 lambda functions.
|
||||
This has some advantages:
|
||||
|
||||
* It allows to use this library on compilers that do not support C++11 lambda functions (essentially most C++03 compilers can be used, see __No_Macros__ to also avoid using variadic macros).
|
||||
* Contract functions (see the `..._precondition`, `..._old`, and `..._postcondition` functions in the example below) can be programmed to fully enforce constant-correctness and other contract requirements at compile-time (see also __Constant_Correctness__).
|
||||
[footnote
|
||||
If C++ allowed lambda functions to capture variables by constant reference (e.g., `[const&] (...) { ... }` or `[const& `[^['variable-name]]`] (...) { ... }`) also lambdas could be used to program contract functors that fully enforce __Constant_Correctness__ at compile-time.
|
||||
Note that C++11 lambda allows to capture variables by value (`[=] (...) { ... }` and `[`[^['variable-name]]`] (...) { ... }`), these value captures are `const` (unless the lambda is explicitly declared `mutable`) but they are not suitable to program postconditions using this library (see __Postconditions__), plus they introduce an extra copy that might be too expensive in general.
|
||||
]
|
||||
* Contracts are separated from function body implementations (see also __Specification_and_Implementation__ and __Separate_Body_Implementation__).
|
||||
|
||||
However, not using C++11 lambda functions comes to the significant cost of having to manually write a great deal of extra code to program the contract functions, for example (see also [@../../example/features/no_lambdas.hpp =no_lambdas.hpp=] and [@../../example/features/no_lambdas.cpp =no_lambdas.cpp=]):
|
||||
|
||||
[import ../example/features/no_lambdas.hpp]
|
||||
[no_lambdas_hpp]
|
||||
|
||||
[import ../example/features/no_lambdas.cpp]
|
||||
[no_lambdas_cpp]
|
||||
|
||||
If programmers also want to fully enforce all contract programming constant-correctness requirements at compile-time, they should follow these rules when programming the contract functions (see also __Constant_Correctness__):
|
||||
|
||||
* Precondition functions (i.e., the `..._precondition` functions in the example above) can take their arguments either by `const` value or by `const&`, and they should be either `static` or `const` member functions.
|
||||
* Postcondition functions (i.e., the `..._postcondition` functions in the example above) should take their arguments by `const&`, and they should be either `static` or `const` member functions.
|
||||
* Old value functions (i.e., the `..._old` functions in the example above) should take their arguments by `const&` a part from old value pointers that should be taken by `&` (so only old value pointers can be modified), and they should be either `static` or `const` member functions.
|
||||
* Constructor precondition and old value functions should be `static` (because constructor preconditions and old values cannot access the object `this`, see also __Constructor_Calls__).
|
||||
* Destructor postcondition functions should be `static` (because destructor postconditions cannot access the object `this`, see also __Destructor_Calls__).
|
||||
|
||||
Note that the extra contract functions also allow to program only the contract code in the header file (see also __Specification_and_Implementation__).
|
||||
All function body implementation code was instead programmed in the source file (including the constructor member initialization list, that could not be done with the technique shown in __Separate_Body_Implementation__).
|
||||
[footnote
|
||||
In this example, `bind` was used to generate nullary functors from the contract functions.
|
||||
As always with `bind`, `cref` and `ref` must be used to bind arguments by `const&` and `&` respectively, plus it might be necessary to explicitly `static_cast` the function pointer passed to `bind` in case the bound function name is overloaded.
|
||||
]
|
||||
Also note that the contract functions can always be declared `private` if programmers need to exactly control the public members of the class (this was not done in this example only for brevity, see also __Access__).
|
||||
|
||||
Alternatively, on compilers that do not support C++11 lambda functions but that support type-of (either native as an extension or via emulation, these should be most recent C++03 compilers), [@http://www.boost.org/doc/libs/release/libs/local_function/doc/html/index.html Boost.LocalFunction] can be used to program the contract functions, for example (see also [@../../example/features/no_lambdas_local_func.cpp =no_lambda_local_func.cpp=]):
|
||||
|
||||
[import ../example/features/no_lambdas_local_func.cpp]
|
||||
[no_lambdas_local_func]
|
||||
|
||||
This code is somewhat less verbose than the previous example (about 30% less lines of code) but the contract code is hard to ready.
|
||||
|
||||
Other libraries could also be used to program the contract functions without C++11 lambda functions (Boost.Lambda, Boost.Fusion, etc.) but like the techniques shown above, they will all result in contract code more verbose, or harder to read and maintain than the contract code programmed using C++11 lambda functions.
|
||||
Therefore, authors think this library is most useful when used together with C++11 lambda functions.
|
||||
|
||||
[endsect]
|
||||
|
||||
[endsect]
|
||||
|
||||
|
||||
302
doc/extras.qbk
Normal file
302
doc/extras.qbk
Normal file
@ -0,0 +1,302 @@
|
||||
|
||||
[/ Copyright (C) 2008-2016 Lorenzo Caminiti]
|
||||
[/ Distributed under the Boost Software License, Version 1.0 (see accompanying]
|
||||
[/ file LICENSE_1_0.txt or a copy at http://www.boost.org/LICENSE_1_0.txt).]
|
||||
[/ See: http://www.boost.org/doc/libs/release/libs/contract/doc/html/index.html]
|
||||
|
||||
[section Extras]
|
||||
|
||||
This section can be consulted selective for specific topics of interest.
|
||||
|
||||
[section Move Operations]
|
||||
|
||||
As with all public operations of a class, also move operations should maintain class invariants (see also __Stroustrup13__, p. 520).
|
||||
Specifically, C++ requires the following:
|
||||
|
||||
* The moved-from object can be copy assigned.
|
||||
* The moved-from object can be move assigned.
|
||||
* The moved-from object can be destroyed.
|
||||
[footnote
|
||||
If not anything else, this requires that class invariants are maintained by move operations because the destructor of the moved-from object requires that class invariants are true at its entry (as always with destructors, see also __Destructor_Calls__).
|
||||
]
|
||||
|
||||
Thus both the move constructor and the move assignment operator need to maintain the class invariants of the moved-from object and their contracts can be programmed using [funcref boost::contract::constructor] and [funcref boost::contract::public_function] as always for constructors and public member functions, for example (see also [@../../example/features/move.cpp =move.cpp=]):
|
||||
|
||||
[import ../example/features/move.cpp]
|
||||
[move]
|
||||
|
||||
This example assumes that it is possible to call the public member function `move()` on the moved-from object.
|
||||
This allows to make explicit the precondition that except for destructor, copy and move assignments all other public member functions cannot be called on a moved-from object.
|
||||
This precondition is usually implicit in C++ (i.e., documented by the standard but not checked by the language at run-time).
|
||||
If it is is not possible (e.g., due to some optimized implementation of the move operations) to have such a public `move()` member function, the private `moved_` member (or similar) can be used to program class invariants and preconditions (and that will just relay on the usual implicit C++ assumption on moved-from object because users will not be able to fully check preconditions and class invariants before calling functions of a moved-from object).
|
||||
|
||||
[note
|
||||
The default move constructor and move assignment operator automatically generated by C++ will not check contracts.
|
||||
Therefore, unless these operations are not public or they have no preconditions, no postconditions, and the class has no invariants, programmers should manually define them using [funcref boost::contract::constructor], [classref boost::contract::constructor_precondition], and [funcref boost::contract::public_function].
|
||||
(Same for all other automatically generated operations.)
|
||||
]
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Unions]
|
||||
|
||||
In C++, a `union` cannot have virtual member functions, bases classes, and cannot be used as a base class thus subcontracting ([classref boost::contract::virtual_], [macroref BOOST_CONTRACT_OVERRIDE], etc.) do not apply to unions.
|
||||
Also a `union` cannot inherit from [classref boost::contract::constructor_precondition] (because it cannot have base classes) so such a class is used to declare a local object that checks constructor preconditions (see `pre` in the example below).
|
||||
A part from that, this library is used as usual to program contracts for unions, for example (see also [@../../example/features/union.cpp =union.cpp=]):
|
||||
|
||||
[import ../example/features/union.cpp]
|
||||
[union]
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Volatile Class Invariants]
|
||||
|
||||
This library allows to specify a different set of class invariants to be checked for public volatile member functions.
|
||||
These /volatile class invariants/ are programmed in a public member function `const volatile` qualified and named `invariant` (see [macroref BOOST_CONTRACT_INVARIANT] to name the invariant function differently from `invariant` and __Access__ to not have to declare it public).
|
||||
|
||||
In general, `const volatile` qualified invariants work the same as `const` qualified invariant (see __Class_Invariants__) with the only difference that `volatile` and `const volatile` member functions check `const volatile` invariants while mutable (i.e., neither `const` nor `volatile` qualified) and `const` member functions check `const` invariants.
|
||||
A given class can specify both `const volatile` and `const` qualified invariant member functions:
|
||||
[footnote
|
||||
*Rationale:*
|
||||
Constructors and destructors check `const volatile` and `const` invariants in that order because the qualifier that limits the calls the least is checked first (note that a `const volatile` calls can be made on any object while `const` calls cannot be made on `volatile` non-`const` objects, in that sense the `const volatile` qualifier limits calls on an object less than `const` alone does).
|
||||
This is consistent with `static` class invariants that are checked even before `const volatile` invariants (the `static` classifier limits calls even less than `const volatile` in the sense that an object is not even needed to make static calls).
|
||||
While there is a more important reason to check `static` invariants before all other invariants (see __Contract_Programming_Overview__), the above is the only reason why this library checks `const volatile` invariants before `const` invariants for constructors and destructors.
|
||||
]
|
||||
|
||||
* Constructors check both `const volatile` and `const` qualified invariants in that order (at exit if no exception is thrown).
|
||||
* Destructors check both `const volatile` and `const` qualified invariants (at entry).
|
||||
* Both mutable and `const` public member functions check `const` qualified invariants (at entry and at exit if no exception is thrown).
|
||||
* Both `volatile` and `const volatile` public member functions check `const volatile` qualified invariants (at entry and at exit if no exception is thrown).
|
||||
|
||||
This ensures that volatile class invariants are correctly checked (see also __Constructor_Calls__, __Destructor_Calls__, and __Public_Function_Calls__).
|
||||
For example (see also [@../../example/features/volatile.cpp =volatile.cpp=]):
|
||||
|
||||
[import ../example/features/volatile.cpp]
|
||||
[volatile]
|
||||
|
||||
While this library does not automatically check `const volatile` invariants for non-volatile functions, programmers can explicitly call the `const volatile` invariant function from the `const` invariant function if that makes sense for the contracts being specified (that way all public member functions `volatile` and not will check `const volatile` invariants):
|
||||
[footnote
|
||||
*Rationale:*
|
||||
Note that while all public member functions can be made to check `const volatile` invariants, it is never possible to make volatile public member functions check `const` non-volatile invariants.
|
||||
That is because both `const` and `volatile` can always be added but never stripped in C++ (a part from forcefully via `const_cast`) but `const` is always automatically added by this library in order to enforce contract constant-correctness (see __Constant_Correctness__).
|
||||
That said, it would be incorrect for this library to also automatically add `volatile` and require all functions to check `const volatile` (not just `const`) invariants because only `volatile` members can be accessed from `const volatile` invariants so there could be many `const` (but not `const volatile`) members that are accessible from `const` invariants but not from `const volatile` invariants.
|
||||
To avoid this confusion, this library has chosen to draw a clear dichotomy between `const` and `const volatile` invariants so that only volatile members check `const volatile` invariants and only non-volatile members check `const` (but not `const volatile`) invariants.
|
||||
This is simple and should serve most cases.
|
||||
If programmers need non-volatile members to check `const volatile` invariants, they can explicitly do so by calling the `const volatile` invariant function from the `const` invariant function as shown in this documentation.
|
||||
]
|
||||
|
||||
class ``[^['class-type]]`` {
|
||||
public:
|
||||
void invariant() const {
|
||||
``[^['class-type]]`` const volatile& cv = *this;
|
||||
cv.invariant(); // Call `void invariant() const volatile` below.
|
||||
...
|
||||
}
|
||||
|
||||
void invariant() const volatile {
|
||||
...
|
||||
}
|
||||
|
||||
...
|
||||
};
|
||||
|
||||
As usual, static class invariants can also be specified (see __Static_Class_Invariants__) and private and protected member functions do not check any invariant (see __Private_and_Protected_Functions__).
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Disable Contract Compilation (Macro Interface)]
|
||||
|
||||
This library provides macros that can be used to disable compile-time overhead introduced by contracts but at the cost of manually programming `#ifdef` statements around contract code.
|
||||
The authors of this library do not recommend to use this practice unless strictly necessary because it makes the contract code more verbose, less readable, and in most applications the compile-time overhead of contracts should not represent an issue (it should be sufficient to disable contract checking at run-time as indicated before).
|
||||
|
||||
In any case, the following example illustrates how to completely disable contract code compilation for non-member functions (see also [@../../example/features/ifdef_macro.cpp =ifdef_macro.cpp=] and [@../../example/features/ifdef.pp =ifdef.cpp=]):
|
||||
|
||||
[import ../example/features/ifdef_macro.cpp]
|
||||
[import ../example/features/ifdef.cpp]
|
||||
[table
|
||||
[ [Macro Interface] [Code Interface] ]
|
||||
[ [[ifdef_macro_function]] [[ifdef_function]] ]
|
||||
]
|
||||
|
||||
The same is done to disable contract code complication for private and protected functions.
|
||||
For constructors, destructors, and public functions instead (see also [@../../example/features/ifdef_macro.cpp =ifdef_macro.cpp=] and [@../../example/features/ifdef.pp =ifdef.cpp=]):
|
||||
|
||||
[table
|
||||
[ [Macro Interface] [Code Interface] ]
|
||||
[ [[ifdef_macro_class]] [[ifdef_class]] ]
|
||||
]
|
||||
|
||||
As shown by the examples above:
|
||||
|
||||
* The [macroref BOOST_CONTRACT_NO_PRECONDITIONS] macro is defined by programmers and it can be used in `#ifdef` statements to disable compilation of preconditions, including constructor preconditions ([classref boost::contract::constructor_precondition]).
|
||||
* The [macroref BOOST_CONTRACT_NO_POSTCONDITIONS] macro is defined by programmers and it can be used in `#ifdef` statements to disable compilation of postconditions, old value declarations, and old value assignments at body (`.old(...)`).
|
||||
* The [macroref BOOST_CONTRACT_NO_INVARIANTS] macro is defined by programmers (or it will be automatically defined by this library if both [macroref BOOST_CONTRACT_NO_ENTRY_INVARIANTS] and [macroref BOOST_CONTRACT_NO_EXIT_INVARIANTS] are defined) and it can be used in `#ifdef` statements to disable compilation of class invariants (including static and volatile class invariants).
|
||||
Also the [macroref BOOST_CONTRACT_NO_ENTRY_INVARIANTS] and [macroref BOOST_CONTRACT_NO_EXIT_INVARIANTS] macros are defined by programmers (or they will be both automatically defined by this library if [macroref BOOST_CONTRACT_NO_INVARIANTS] is defined) but these macros are not directly used to disable contract code compilation (only contract code run-time checking).
|
||||
* The [macroref BOOST_CONTRACT_NO_CONSTRUCTORS] macro is automatically defined by this library (a compile-time error will be reported if programmes try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of constructor contract guards.
|
||||
* The [macroref BOOST_CONTRACT_NO_DESTRUCTORS] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of destructor contract guards.
|
||||
* The [macroref BOOST_CONTRACT_NO_PUBLIC_FUNCTIONS] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of public member function contract guards, base type `typedef`, extra [classref boost::contract::virtual_] function parameters, and [macroref BOOST_CONTRACT_OVERRIDE] declarations.
|
||||
* The [macroref BOOST_CONTRACT_NO_FUNCTIONS] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable compilation of contract guards for non-member functions as well as private and protected functions.
|
||||
* The [macroref BOOST_CONTRACT_NO_ALL] macro is automatically defined by this library (a compile-time error will be reported if programmers try to manually define this macro) and it can be used in `#ifdef` statements to disable [classref boost::contract::access] friendship declarations and also inclusions of [headerref boost/contract.hpp] (some of the other macros listed here can be used to selectively disable inclusion of =boost/contract/*.hpp= headers when they are used instead of [headerref boost/contract.hpp].)
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Implementation Checks]
|
||||
|
||||
[endsect]
|
||||
|
||||
[section Separate Body Implementation (No C++11 Lambdas)]
|
||||
|
||||
Contracts are part of the program specification and not of its implementation (see also __Specification_and_Implementation__).
|
||||
However, this library uses function definitions to program the contracts so contract code appears together with the function implementation code.
|
||||
This is not ideal, but contract code programmed with this library must always appear at the very top of the function definition so programmers will easily be able to distinguish it from the rest of function implementation code (so this might not be real problem in practise).
|
||||
|
||||
In some cases, it might be desirable to completely separate the contract code (function specification) from the function body code (function implementation).
|
||||
For example, this could be necessary for software that ships only header files and pre-compiled source code to its users (notably, that cannot be done for template code in C++).
|
||||
If the contracts are programmed in the function definitions that are pre-compiled with the source code, users will not be able to inspect the contract code to understand semantics and usage of the functions (again, this might not be a real problem in practice for example if contract code is already somehow extracted from the source code and presented as part of the documentation of the shipped software).
|
||||
|
||||
In such cases, the function implementation can be programmed in an extra /body function/ (e.g., named `..._body`) that is defined in the source code.
|
||||
The original function definition remains in the header files instead, it programs the contract and simply calls the extra body function.
|
||||
At the cost of programmers writing an extra function declaration for the body function, this technique allows to keep the contract code in header files while separating the body implementation code to source files (with the limitation that constructor member initialization lists must still be programmed in the header files because that is where the constructors are actually defined).
|
||||
|
||||
For example, the following header file only contains function declarations and contract code (function specifications) and constructor member initializations (see also [@../../example/features/separate_body.hpp =separate_body.hpp=]):
|
||||
|
||||
[import ../example/features/separate_body.hpp]
|
||||
[separate_body_hpp]
|
||||
|
||||
Instead, the function bodies (function implementations) is programmed in a separate source file (see also [@../../example/features/separate_body.cpp =separate_body.cpp=]):
|
||||
|
||||
[import ../example/features/separate_body.cpp]
|
||||
[separate_body_cpp]
|
||||
|
||||
The same technique can be used for non-member, private, and protected functions.
|
||||
|
||||
[note
|
||||
When contracts are programmed in a separate =.cpp= files and also /all/ these library headers are `#include`d only from =.cpp= files, then the =.cpp= files can be compiled disabling specific contract checking (for example, [macroref BOOST_CONTRACT_NO_POSTCONDITIONS] and [macroref BOOST_CONTRACT_NO_EXIT_INVARIANTS], see __Disable_Contract_Checking__).
|
||||
The user code that will link to these =.cpp= files not be able to
|
||||
Then the code in these =.cpp= files will always have such contract checking disabled even when linked to some other user code that might have been compiled with a different set of disable contracts (i.e., a different `BOOST_CONTRACT_NO_...` defined).
|
||||
This technique might be useful to ship a pre-compiled set of object files (e.g., for a library) that will never check some contracts (e.g., postconditions and exit invariants) regardless of the definition of the `BOOST_CONTRACT_NO_...` macros used to compile code that uses such object files.
|
||||
|
||||
On the contrary, if contracts are programmed in header files and this library headers are `#include`d in header files that are being shipped, then end users enable or disables contracts of the shipped code by defining `BOOST_CONTRACT_NO_...` when they compiled the shipped header files as part of their code.
|
||||
This technique might be useful in other situations when programmers that ship code want instead to leave it up the their end users to decide which contracts in the shipped code should be checked at run-time.
|
||||
]
|
||||
|
||||
[endsect]
|
||||
|
||||
[section No Macros (No C++11)]
|
||||
|
||||
It is possible to specify contracts without using this library macros and programming the related code manually instead (a part from [macroref BOOST_CONTRACT_OVERRIDE], [macroref BOOST_CONTRACT_OVERRIDES], and [macroref BOOST_CONTRACT_NAMED_OVERRIDE] that cannot be programmed manually).
|
||||
|
||||
Some of this library macros are variadic macros, others are not (see below).
|
||||
Variadic macros were officially added to the language since C++11 but most compilers have been supporting variadic macros as an extension for a long time, plus essentially all compilers that support C++11 lambda functions also support C++11 variadic macros (and this library might rarely be used without the convenience of C++11 lambda functions, see also __No_Lambda_Functions__).
|
||||
Therefore, the following can be considered mainly a curiosity because programmers should seldom need to use this library without using its macros.
|
||||
|
||||
[heading Overrides]
|
||||
|
||||
As shown in __Public_Function_Overrides__ and __Named_Overrides__, this library provides the [macroref BOOST_CONTRACT_OVERRIDE] and [macroref BOOST_CONTRACT_NAMED_OVERRIDE] macros to program contracts for overriding public functions.
|
||||
These macros cannot be programmed manually but they are not variadic macros so programmers should be able to use them on all C++ compilers.
|
||||
[footnote
|
||||
*Rationale:*
|
||||
These macros expand SFINAE-based introspection templates that cannot be reasonably programmed by users (that remains the case even if C++14 generic lambdas were to be used here).
|
||||
]
|
||||
The [macroref BOOST_CONTRACT_OVERRIDES] macro is a variadic macro instead but programmes can manually repeat the non-variadic macro [macroref BOOST_CONTRACT_OVERRIDE] for each overriding public function name on compilers that do not support variadic macros.
|
||||
|
||||
[heading Assertions (Not Variadic)]
|
||||
|
||||
As shown in __Preconditions__, __Postconditions__, __Class_Invariants__, etc. this library provides the [macroref BOOST_CONTRACT_ASSERT] macro to assert contract conditions.
|
||||
This is not a variadic macro and programmers should be able to use it on all C++ compilers.
|
||||
However, the macro invocation `BOOST_CONTRACT_ASSERT(`[^['condition]]`)` simply expands to code equivalent to the following:
|
||||
|
||||
if(!``[^['condition]]``) {
|
||||
throw boost::contract::assertion_failure(__FILE__, __LINE__,
|
||||
BOOST_PP_STRINGIZE(``[^['condition]]``));
|
||||
}
|
||||
|
||||
That is because this library considers any exception thrown from within preconditions, postconditions, and class invariants as a contract failure and reports it calling the related contract failure handler ([funcref boost::contract::precondition_failure], etc., see also __Throw_on_Failure__).
|
||||
In fact, if there is a need for it, programmers can always program contract assertions that throw an exception as follow (see [@../../example/features/throw_on_failure.cpp =throw_on_failure.cpp=] for an example):
|
||||
|
||||
if(!``[^['condition]]``) throw ``[^['exception-type]]``(...);
|
||||
|
||||
However, using [macroref BOOST_CONTRACT_ASSERT] always allows this library to show detailed information about the assertion code, its file and line number, etc.
|
||||
|
||||
[heading Base Types (Variadic)]
|
||||
|
||||
As shown in __Base_Classes__, this library provides the [macroref BOOST_CONTRACT_BASE_TYPES] variadic macro to declare the `base_types` member type that lists all public bases of a derived class.
|
||||
Programmers can also declare `base_types` without using [macroref BOOST_CONTRACT_BASE_TYPES] at the cost of writing a bit more code manually, for example (see also [@../../example/features/base_types_no_macros.cpp =base_types_no_macros.cpp=]):
|
||||
|
||||
[import ../example/features/base_types_no_macros.cpp]
|
||||
[base_types_no_macros]
|
||||
|
||||
The `base_types` member type must be a `boost::mpl::vector` and it must list /only/ `public` base classes (because only public bases subcontract, see also __Function_Calls__).
|
||||
If the [macroref BOOST_CONTRACT_BASE_TYPES] macro is not used, it is the responsibility of the programmers to maintain the correct list of bases in the `boost::mpl::vector` each time the derived class inheritance list changes (this might complicate maintenance).
|
||||
In general, it is recommended to use the [macroref BOOST_CONTRACT_BASE_TYPES] macro if possible.
|
||||
|
||||
[heading Old Values (Variadic)]
|
||||
|
||||
As shown in __Old_Values__, this library provides the [macroref BOOST_CONTRACT_OLDOF] variadic macro to assign old value copies.
|
||||
Programmers can also assign old values without using [macroref BOOST_CONTRACT_OLDOF] at the cost of writing a bit more code manually, for example (see also [@../../example/features/old_no_macros.cpp =old_no_macros.cpp=]):
|
||||
|
||||
[import ../example/features/old_no_macros.cpp]
|
||||
[old_no_macros]
|
||||
|
||||
The ternary operator `boost::contract::copy_old(v) ? size() : boost::contract::null_old()` must be used here to avoid evaluating and copying the old value expression `size()` when [funcref boost::contract::copy_old] returns `false` because old values are not being copied (postcondition checking is disable at run-time, an overridden virtual function call is not checking postconditions yet, etc.).
|
||||
The enclosing [funcref boost::contract::make_old] copies the old value expression and creates an old value pointer, while [funcref boost::contract::null_old] indicates when a null old value pointer should be created.
|
||||
|
||||
The [funcref boost::contract::make_old] and [funcref boost::contract::copy_old] functions are used exactly as above but without the extra `v` parameter when they are called from within non-virtual functions (see also __Public_Function_Overrides__).
|
||||
The old value pointer returned by [funcref boost::contract::make_old] can be assigned to either [classref boost::contract::old_ptr] or [classref boost::contract::noncoyable_old_ptr] (see also __Old_Value_Requirements__).
|
||||
|
||||
In general, it is recommended to use the [macroref BOOST_CONTRACT_OLDOF] macro if possible.
|
||||
|
||||
[endsect]
|
||||
|
||||
[section No Lambda Functions (No C++11)]
|
||||
|
||||
This section shows how to use this library without C++11 lambda functions.
|
||||
This has some advantages:
|
||||
|
||||
* It allows to use this library on compilers that do not support C++11 lambda functions (essentially most C++03 compilers can be used, see __No_Macros__ to also avoid using variadic macros).
|
||||
* Contract functions (see the `..._precondition`, `..._old`, and `..._postcondition` functions in the example below) can be programmed to fully enforce constant-correctness and other contract requirements at compile-time (see also __Constant_Correctness__).
|
||||
[footnote
|
||||
If C++ allowed lambda functions to capture variables by constant reference (e.g., `[const&] (...) { ... }` or `[const& `[^['variable-name]]`] (...) { ... }`) also lambdas could be used to program contract functors that fully enforce __Constant_Correctness__ at compile-time.
|
||||
Note that C++11 lambda allows to capture variables by value (`[=] (...) { ... }` and `[`[^['variable-name]]`] (...) { ... }`), these value captures are `const` (unless the lambda is explicitly declared `mutable`) but they are not suitable to program postconditions using this library (see __Postconditions__), plus they introduce an extra copy that might be too expensive in general.
|
||||
]
|
||||
* Contracts are separated from function body implementations (see also __Specification_and_Implementation__ and __Separate_Body_Implementation__).
|
||||
|
||||
However, not using C++11 lambda functions comes to the significant cost of having to manually write a great deal of extra code to program the contract functions, for example (see also [@../../example/features/no_lambdas.hpp =no_lambdas.hpp=] and [@../../example/features/no_lambdas.cpp =no_lambdas.cpp=]):
|
||||
|
||||
[import ../example/features/no_lambdas.hpp]
|
||||
[no_lambdas_hpp]
|
||||
|
||||
[import ../example/features/no_lambdas.cpp]
|
||||
[no_lambdas_cpp]
|
||||
|
||||
If programmers also want to fully enforce all contract programming constant-correctness requirements at compile-time, they should follow these rules when programming the contract functions (see also __Constant_Correctness__):
|
||||
|
||||
* Precondition functions (i.e., the `..._precondition` functions in the example above) can take their arguments either by `const` value or by `const&`, and they should be either `static` or `const` member functions.
|
||||
* Postcondition functions (i.e., the `..._postcondition` functions in the example above) should take their arguments by `const&`, and they should be either `static` or `const` member functions.
|
||||
* Old value functions (i.e., the `..._old` functions in the example above) should take their arguments by `const&` a part from old value pointers that should be taken by `&` (so only old value pointers can be modified), and they should be either `static` or `const` member functions.
|
||||
* Constructor precondition and old value functions should be `static` (because constructor preconditions and old values cannot access the object `this`, see also __Constructor_Calls__).
|
||||
* Destructor postcondition functions should be `static` (because destructor postconditions cannot access the object `this`, see also __Destructor_Calls__).
|
||||
|
||||
Note that the extra contract functions also allow to program only the contract code in the header file (see also __Specification_and_Implementation__).
|
||||
All function body implementation code was instead programmed in the source file (including the constructor member initialization list, that could not be done with the technique shown in __Separate_Body_Implementation__).
|
||||
[footnote
|
||||
In this example, `bind` was used to generate nullary functors from the contract functions.
|
||||
As always with `bind`, `cref` and `ref` must be used to bind arguments by `const&` and `&` respectively, plus it might be necessary to explicitly `static_cast` the function pointer passed to `bind` in case the bound function name is overloaded.
|
||||
]
|
||||
Also note that the contract functions can always be declared `private` if programmers need to exactly control the public members of the class (this was not done in this example only for brevity, see also __Access__).
|
||||
|
||||
Alternatively, on compilers that do not support C++11 lambda functions but that support type-of (either native as an extension or via emulation, these should be most recent C++03 compilers), [@http://www.boost.org/doc/libs/release/libs/local_function/doc/html/index.html Boost.LocalFunction] can be used to program the contract functions, for example (see also [@../../example/features/no_lambdas_local_func.cpp =no_lambda_local_func.cpp=]):
|
||||
|
||||
[import ../example/features/no_lambdas_local_func.cpp]
|
||||
[no_lambdas_local_func]
|
||||
|
||||
This code is somewhat less verbose than the previous example (about 30% less lines of code) but the contract code is hard to ready.
|
||||
|
||||
Other libraries could also be used to program the contract functions without C++11 lambda functions (Boost.Lambda, Boost.Fusion, etc.) but like the techniques shown above, they will all result in contract code more verbose, or harder to read and maintain than the contract code programmed using C++11 lambda functions.
|
||||
Therefore, authors think this library is most useful when used together with C++11 lambda functions.
|
||||
|
||||
[endsect]
|
||||
|
||||
[endsect]
|
||||
|
||||
|
||||
@ -10,14 +10,8 @@
|
||||
[authors [Caminiti <email>lorcaminiti@gmail.com</email>, Lorenzo]]
|
||||
[copyright 2008-2016 Lorenzo Caminiti]
|
||||
[license Distributed under the Boost Software License, Version 1.0 (see accompanying file LICENSE_1_0.txt or a copy at [@http://www.boost.org/LICENSE_1_0.txt])]
|
||||
[/ purpose Contract Programming for C++]
|
||||
[/ category Correctness and Testing]
|
||||
]
|
||||
|
||||
[template file[dir name] '''<ulink url="../../'''[dir]'''/'''[name]'''">'''[^[name]]'''</ulink>''']
|
||||
|
||||
[def __substitution_principle__ [@http://en.wikipedia.org/wiki/Liskov_substitution_principle substitution principle]]
|
||||
|
||||
[def __Introduction__ [link boost_contract.introduction Introduction]]
|
||||
[def __Getting_Started__ [link boost_contract.getting_started Getting Started]]
|
||||
|
||||
@ -99,6 +93,8 @@
|
||||
[def __Stroustrup13__ [link Stroustrup13_anchor \[Stroustrup13\]]]
|
||||
[def __Tandin04__ [link Tandin04_anchor \[Tandin04\]]]
|
||||
|
||||
[def __substitution_principle__ [@http://en.wikipedia.org/wiki/Liskov_substitution_principle substitution principle]]
|
||||
|
||||
[:['["Our field needs more formality, but the profession has not realized it yet.]]]
|
||||
[:['-- Bertrand Meyer (see __Meyer97__ page 400)]]
|
||||
|
||||
@ -122,6 +118,7 @@ This library source is hosted at [@https://github.com/lcaminiti/boost-contract].
|
||||
[include contract_programming_overview.qbk]
|
||||
[include tutorial.qbk]
|
||||
[include advanced_topics.qbk]
|
||||
[include extras.qbk]
|
||||
[xinclude reference.xml]
|
||||
[include examples.qbk]
|
||||
[include release_notes.qbk]
|
||||
|
||||
@ -9,14 +9,15 @@
|
||||
#include <cassert>
|
||||
|
||||
//[ifdef_function
|
||||
// Use #ifdef to selectively disable contract compilation.
|
||||
#ifndef BOOST_CONTRACT_NO_ALL
|
||||
#include <boost/contract.hpp>
|
||||
#endif
|
||||
|
||||
int inc(int& x) {
|
||||
int result;
|
||||
#ifndef BOOST_CONTRACT_NO_POSTCONDITIONS
|
||||
boost::contract::old_ptr<int> old_x = BOOST_CONTRACT_OLD(x);
|
||||
#ifndef BOOST_CONTRACT_NO_OLDS
|
||||
boost::contract::old_ptr<int> old_x = BOOST_CONTRACT_OLDOF(x);
|
||||
#endif
|
||||
#ifndef BOOST_CONTRACT_NO_FUNCTIONS
|
||||
boost::contract::check c = boost::contract::function()
|
||||
@ -63,16 +64,16 @@ protected:
|
||||
virtual unsigned max_size() const = 0;
|
||||
};
|
||||
|
||||
template<typename T> // Contract for pure virtual function.
|
||||
template<typename T>
|
||||
void pushable<T>::push_back(
|
||||
T const& x
|
||||
#ifndef BOOST_CONTRACT_NO_PUBLIC_FUNCTIONS
|
||||
, boost::contract::virtual_* v
|
||||
#endif
|
||||
) {
|
||||
#ifndef BOOST_CONTRACT_NO_POSTCONDITIONS
|
||||
#ifndef BOOST_CONTRACT_NO_OLDS
|
||||
boost::contract::old_ptr<unsigned> old_capacity =
|
||||
BOOST_CONTRACT_OLD(v, capacity());
|
||||
BOOST_CONTRACT_OLDOF(v, capacity());
|
||||
#endif
|
||||
#ifndef BOOST_CONTRACT_NO_PUBLIC_FUNCTIONS
|
||||
boost::contract::check c = boost::contract::public_function(v, this)
|
||||
@ -121,8 +122,7 @@ public:
|
||||
#ifndef BOOST_CONTRACT_NO_PRECONDITIONS
|
||||
boost::contract::constructor_precondition<integers>([&] {
|
||||
BOOST_CONTRACT_ASSERT(from <= to);
|
||||
})
|
||||
,
|
||||
}),
|
||||
#endif
|
||||
vect_(to - from + 1)
|
||||
{
|
||||
@ -152,7 +152,7 @@ public:
|
||||
, boost::contract::virtual_* v = 0
|
||||
#endif
|
||||
) /* override */ {
|
||||
#ifndef BOOST_CONTRACT_NO_POSTCONDITIONS
|
||||
#ifndef BOOST_CONTRACT_NO_OLDS
|
||||
boost::contract::old_ptr<unsigned> old_size;
|
||||
#endif
|
||||
#ifndef BOOST_CONTRACT_NO_PUBLIC_FUNCTIONS
|
||||
@ -163,14 +163,21 @@ public:
|
||||
BOOST_CONTRACT_ASSERT(size() < max_size());
|
||||
})
|
||||
#endif
|
||||
#ifndef BOOST_CONTRACT_NO_POSTCONDITIONS
|
||||
#ifndef BOOST_CONTRACT_NO_OLDS
|
||||
.old([&] {
|
||||
old_size = BOOST_CONTRACT_OLD(v, size());
|
||||
old_size = BOOST_CONTRACT_OLDOF(v, size());
|
||||
})
|
||||
#endif
|
||||
#ifndef BOOST_CONTRACT_NO_POSTCONDITIONS
|
||||
.postcondition([&] {
|
||||
BOOST_CONTRACT_ASSERT(size() == *old_size + 1);
|
||||
})
|
||||
#endif
|
||||
#ifndef BOOST_CONTRACT_NO_EXCEPTS
|
||||
.except([&] {
|
||||
BOOST_CONTRACT_ASSERT(size() == *old_size);
|
||||
})
|
||||
#endif
|
||||
;
|
||||
#endif
|
||||
|
||||
|
||||
@ -5,40 +5,33 @@
|
||||
// See: http://www.boost.org/doc/libs/release/libs/contract/doc/html/index.html
|
||||
|
||||
#include <vector>
|
||||
#include <memory>
|
||||
#include <utility>
|
||||
#include <limits>
|
||||
#include <cassert>
|
||||
|
||||
//[ifdef_macro_function
|
||||
// Use macro interface to selectively disable contract compilation.
|
||||
#include <boost/contract_macro.hpp>
|
||||
|
||||
std::pair<int, int> inc(std::pair<int, int>& p) {
|
||||
std::pair<int, int> result;
|
||||
BOOST_CONTRACT_OLD_PTR(std::pair<int, int>)(old_pt, p);
|
||||
int inc(int& x) {
|
||||
int result;
|
||||
BOOST_CONTRACT_OLD_PTR(int)(old_x, x);
|
||||
BOOST_CONTRACT_FUNCTION()
|
||||
BOOST_CONTRACT_PRECONDITION([&] {
|
||||
BOOST_CONTRACT_ASSERT(p.first < std::numeric_limits<int>::max());
|
||||
BOOST_CONTRACT_ASSERT(p.second < std::numeric_limits<int>::max());
|
||||
BOOST_CONTRACT_ASSERT(x < std::numeric_limits<int>::max());
|
||||
})
|
||||
BOOST_CONTRACT_POSTCONDITION([&] {
|
||||
BOOST_CONTRACT_ASSERT(p.first == old_pt->first + 1);
|
||||
BOOST_CONTRACT_ASSERT(p.second == old_pt->second + 1);
|
||||
BOOST_CONTRACT_ASSERT(result.first == old_pt->first);
|
||||
BOOST_CONTRACT_ASSERT(result.second == old_pt->second);
|
||||
BOOST_CONTRACT_ASSERT(x == *old_x + 1);
|
||||
BOOST_CONTRACT_ASSERT(result == *old_x);
|
||||
})
|
||||
;
|
||||
|
||||
result = p;
|
||||
++p.first;
|
||||
++p.second;
|
||||
return result;
|
||||
return result = x++;
|
||||
}
|
||||
//]
|
||||
|
||||
template<typename T, typename U>
|
||||
template<typename T>
|
||||
class pushable {
|
||||
friend class boost::contract::access; // OK to always leave this in code.
|
||||
friend class boost::contract::access; // OK if this always left in code.
|
||||
|
||||
BOOST_CONTRACT_INVARIANT({
|
||||
BOOST_CONTRACT_ASSERT(capacity() <= max_size());
|
||||
@ -46,8 +39,8 @@ class pushable {
|
||||
|
||||
public:
|
||||
virtual void push_back(
|
||||
std::pair<T, U> const& p,
|
||||
boost::contract::virtual_* v = 0 // OK to always leave this in code.
|
||||
T const& x,
|
||||
boost::contract::virtual_* v = 0 // OK if this always left in code.
|
||||
) = 0;
|
||||
|
||||
protected:
|
||||
@ -55,9 +48,8 @@ protected:
|
||||
virtual unsigned max_size() const = 0;
|
||||
};
|
||||
|
||||
template<typename T, typename U> // Contract for pure virtual function.
|
||||
void pushable<T, U>::push_back(std::pair<T, U> const& p,
|
||||
boost::contract::virtual_* v) {
|
||||
template<typename T>
|
||||
void pushable<T>::push_back(T const& x, boost::contract::virtual_* v) {
|
||||
BOOST_CONTRACT_OLD_PTR(unsigned)(v, old_capacity, capacity());
|
||||
BOOST_CONTRACT_PUBLIC_FUNCTION(v, this)
|
||||
BOOST_CONTRACT_PRECONDITION([&] {
|
||||
@ -71,24 +63,24 @@ void pushable<T, U>::push_back(std::pair<T, U> const& p,
|
||||
}
|
||||
|
||||
//[ifdef_macro_class
|
||||
template<typename Int, class Alloc = std::allocator<Int> >
|
||||
class integers
|
||||
#define BASES public pushable<Int, Int>
|
||||
#define BASES public pushable<int>
|
||||
:
|
||||
private boost::contract::constructor_precondition<
|
||||
integers<Int, Alloc> >, // OK to always leave this in code.
|
||||
// OK if following extra base class always left in code.
|
||||
private boost::contract::constructor_precondition<integers>,
|
||||
BASES
|
||||
{
|
||||
// These can be left in the code.
|
||||
// OK if followings always left in code.
|
||||
friend class boost::contract::access;
|
||||
typedef BOOST_CONTRACT_BASE_TYPES(BASES) base_types;
|
||||
#undef BASES
|
||||
|
||||
BOOST_CONTRACT_INVARIANT({
|
||||
BOOST_CONTRACT_ASSERT(size() <= capacity());
|
||||
})
|
||||
|
||||
public:
|
||||
integers(Int from, Int to) :
|
||||
integers(int from, int to) :
|
||||
BOOST_CONTRACT_CONSTRUCTOR_PRECONDITION(integers)([&] {
|
||||
BOOST_CONTRACT_ASSERT(from <= to);
|
||||
}),
|
||||
@ -100,22 +92,18 @@ public:
|
||||
})
|
||||
;
|
||||
|
||||
for(Int x = from; x <= to; ++x) {
|
||||
vect_.at(x - from) = std::pair<Int, Int>(x, x);
|
||||
}
|
||||
for(int x = from; x <= to; ++x) vect_.at(x - from) = x;
|
||||
}
|
||||
|
||||
virtual ~integers() {
|
||||
BOOST_CONTRACT_DESTRUCTOR(this); // Check invariants.
|
||||
}
|
||||
|
||||
virtual void push_back(
|
||||
std::pair<Int, Int> const& p,
|
||||
boost::contract::virtual_* v = 0 // OK to always leave this in code.
|
||||
) /* override */ {
|
||||
virtual void push_back(int const& x, boost::contract::virtual_* v = 0)
|
||||
/* override */ {
|
||||
BOOST_CONTRACT_OLD_PTR(unsigned)(old_size);
|
||||
BOOST_CONTRACT_PUBLIC_FUNCTION_OVERRIDE(override_push_back)(v,
|
||||
&integers::push_back, this, p)
|
||||
BOOST_CONTRACT_PUBLIC_FUNCTION_OVERRIDE(override_push_back)(
|
||||
v, &integers::push_back, this, x)
|
||||
BOOST_CONTRACT_PRECONDITION([&] {
|
||||
BOOST_CONTRACT_ASSERT(size() < max_size());
|
||||
})
|
||||
@ -130,11 +118,11 @@ public:
|
||||
})
|
||||
;
|
||||
|
||||
vect_.push_back(p);
|
||||
vect_.push_back(x);
|
||||
}
|
||||
|
||||
private:
|
||||
BOOST_CONTRACT_OVERRIDE(push_back) // OK to always leave this in code.
|
||||
BOOST_CONTRACT_OVERRIDE(push_back) // OK if always left in code.
|
||||
|
||||
/* ... */
|
||||
//]
|
||||
@ -145,22 +133,15 @@ public: // Could program contracts for these too...
|
||||
unsigned capacity() const { return vect_.capacity(); }
|
||||
|
||||
private:
|
||||
std::vector<std::pair<Int, Int>, Alloc> vect_;
|
||||
std::vector<int> vect_;
|
||||
};
|
||||
|
||||
int main() {
|
||||
std::pair<int, int> p(123, 456);
|
||||
std::pair<int, int> q = inc(p);
|
||||
BOOST_CONTRACT_CHECK(p.first == 124);
|
||||
BOOST_CONTRACT_CHECK(p.second == 457);
|
||||
BOOST_CONTRACT_CHECK(q.first == 123);
|
||||
BOOST_CONTRACT_CHECK(q.second == 456);
|
||||
|
||||
integers<int> i(1, 10);
|
||||
i.push_back(inc(q));
|
||||
BOOST_CONTRACT_CHECK(q.first == 124);
|
||||
BOOST_CONTRACT_CHECK(q.second == 457);
|
||||
BOOST_CONTRACT_CHECK(i.size() == 11);
|
||||
integers i(1, 10);
|
||||
int x = 123;
|
||||
i.push_back(inc(x));
|
||||
assert(x == 124);
|
||||
assert(i.size() == 11);
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
@ -45,7 +45,6 @@ never be used directly by programmers.
|
||||
|
||||
// TODO: Documentation updates based on all n-papers that I read recently (review notes I wrote on all papers), add those n-papers to the Bibliography section, and add P0380 (the most recent proposal) to the feature comparison table.
|
||||
|
||||
#include <boost/contract/detail/all_core_headers.hpp>
|
||||
#include <boost/contract/assert.hpp>
|
||||
#include <boost/contract/base_types.hpp>
|
||||
#include <boost/contract/call_if.hpp>
|
||||
|
||||
@ -9,6 +9,8 @@
|
||||
|
||||
// TODO: Document that using an auto declaration instead of check will cause a compile-time error (instead missing check and using no declaration at all will cause a run-time error--as already documented).
|
||||
|
||||
// TODO: Document check (class) and CHECK (macro) to program implementation assertions (for loops, code blocks, etc.) similar to C-style assert() but can be disabled, calls check_failure hander, etc.
|
||||
|
||||
/** @file
|
||||
RAII object to check contracts.
|
||||
*/
|
||||
|
||||
@ -24,7 +24,12 @@
|
||||
#include <boost/contract/assert.hpp>
|
||||
#endif
|
||||
|
||||
// TODO: Document this will cause all pre, post, inv assertions to have the same line number (but different code text) in the error message.
|
||||
// TODO: Document these macros will cause all pre, post, inv assertions to have the same line number (but different code text) in the error message. And that is bad for compiler errors while programming contracts as well (all on same line... and more cryptic).
|
||||
|
||||
// TODO: Add tests for all variadic macros defined here (with unwrapped commas in code, types, etc.).
|
||||
|
||||
// TODO: Make sure there are test for /all/ these macros (OLD_PTR_IF_COPYABLE, EXPECT, INVARIANT_VOLATILE, etc.).
|
||||
|
||||
// PRECONDITION(ftor,,,)
|
||||
#ifndef BOOST_CONTRACT_NO_PRECONDITIONS
|
||||
#define BOOST_CONTRACT_PRECONDITION(...) .precondition(__VA_ARGS__)
|
||||
@ -34,7 +39,7 @@
|
||||
|
||||
// OLD(ftor,,,)
|
||||
//
|
||||
// OLD_PTR[_IF_COPYABLE](type,,,)(name);
|
||||
// OLD_PTR[_IF_COPYABLE](type,,,)(name); // This is never (v, name)!!
|
||||
// OLD_PTR[_IF_COPYABLE](type,,,)(name, value);
|
||||
// OLD_PTR[_IF_COPYABLE](type,,,)(v, name, value);
|
||||
#ifndef BOOST_CONTRACT_NO_OLDS
|
||||
@ -77,7 +82,6 @@
|
||||
#define BOOST_CONTRACT_POSTCONDITION(...) /* nothing */
|
||||
#endif
|
||||
|
||||
// TODO: Added .except and EXCEPT to ifdef and ifdef_macro tests.
|
||||
// EXCEPT(ftor,,,)
|
||||
#ifndef BOOST_CONTRACT_NO_EXCEPTS
|
||||
#define BOOST_CONTRACT_EXCEPT(...) .except(__VA_ARGS__)
|
||||
|
||||
@ -8,6 +8,8 @@ make help : : help_exit ;
|
||||
explicit help ;
|
||||
|
||||
test-suite constructor :
|
||||
[ subdir-run constructor : smoke ]
|
||||
|
||||
[ subdir-run constructor : decl_pre_all ]
|
||||
[ subdir-run constructor : decl_pre_ends ]
|
||||
[ subdir-run constructor : decl_pre_mid ]
|
||||
@ -35,9 +37,8 @@ test-suite constructor :
|
||||
[ subdir-run constructor : decl_exit_inv_mid ]
|
||||
[ subdir-run constructor : decl_exit_inv_none ]
|
||||
|
||||
[ subdir-run constructor : basic ]
|
||||
[ subdir-run constructor : access ]
|
||||
|
||||
|
||||
[ subdir-run constructor : ifdef ]
|
||||
[ subdir-run constructor : ifdef_macro ]
|
||||
|
||||
@ -51,6 +52,8 @@ test-suite constructor :
|
||||
;
|
||||
|
||||
test-suite destructor :
|
||||
[ subdir-run destructor : smoke ]
|
||||
|
||||
# No decl_pre_... for destructors.
|
||||
|
||||
[ subdir-run destructor : decl_post_all ]
|
||||
@ -74,8 +77,7 @@ test-suite destructor :
|
||||
[ subdir-run destructor : decl_entry_inv_none ]
|
||||
|
||||
# No decl_exit_inv_... for destructors.
|
||||
|
||||
[ subdir-run destructor : basic ]
|
||||
|
||||
[ subdir-run destructor : access ]
|
||||
|
||||
[ subdir-run destructor : ifdef ]
|
||||
@ -91,6 +93,8 @@ test-suite destructor :
|
||||
;
|
||||
|
||||
test-suite public_function :
|
||||
[ subdir-run public_function : smoke ]
|
||||
|
||||
[ subdir-run public_function : decl_pre_all ]
|
||||
[ subdir-run public_function : decl_pre_ends ]
|
||||
[ subdir-run public_function : decl_pre_mid ]
|
||||
@ -121,9 +125,8 @@ test-suite public_function :
|
||||
[ subdir-run public_function : decl_exit_inv_mid ]
|
||||
[ subdir-run public_function : decl_exit_inv_none ]
|
||||
|
||||
[ subdir-run public_function : basic ]
|
||||
[ subdir-run public_function : access ]
|
||||
|
||||
|
||||
[ subdir-run public_function : ifdef ]
|
||||
[ subdir-run public_function : ifdef_macro ]
|
||||
|
||||
@ -202,13 +205,13 @@ test-suite invariant :
|
||||
;
|
||||
|
||||
test-suite function :
|
||||
[ subdir-run function : smoke ]
|
||||
|
||||
[ subdir-run function : decl_pre_all ]
|
||||
[ subdir-run function : decl_pre_none ]
|
||||
|
||||
[ subdir-run function : decl_post_all ]
|
||||
[ subdir-run function : decl_post_none ]
|
||||
|
||||
[ subdir-run function : basic ]
|
||||
|
||||
[ subdir-run function : ifdef ]
|
||||
[ subdir-run function : ifdef_macro ]
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
// Test public member function subcontracting.
|
||||
|
||||
#include "basic.hpp"
|
||||
#include "smoke.hpp"
|
||||
#include <boost/preprocessor/control/iif.hpp>
|
||||
#include <boost/detail/lightweight_test.hpp>
|
||||
#include <sstream>
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
// Test public member function body throws with subcontracting.
|
||||
|
||||
#include "basic.hpp"
|
||||
#include "smoke.hpp"
|
||||
#include <boost/optional.hpp>
|
||||
#include <boost/preprocessor/control/iif.hpp>
|
||||
#include <boost/detail/lightweight_test.hpp>
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
// Test virtual public member function body throws with subcontracting.
|
||||
|
||||
#include "basic.hpp"
|
||||
#include "smoke.hpp"
|
||||
#include <boost/optional.hpp>
|
||||
#include <boost/preprocessor/control/iif.hpp>
|
||||
#include <boost/detail/lightweight_test.hpp>
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
// Test virt pub func body throws with subcontr from middle of inheritance tree.
|
||||
|
||||
#include "basic.hpp"
|
||||
#include "smoke.hpp"
|
||||
#include <boost/optional.hpp>
|
||||
#include <boost/preprocessor/control/iif.hpp>
|
||||
#include <boost/detail/lightweight_test.hpp>
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
// Test public function subcontracting via virtual functions.
|
||||
|
||||
#include "basic.hpp"
|
||||
#include "smoke.hpp"
|
||||
#include <boost/preprocessor/control/iif.hpp>
|
||||
#include <boost/detail/lightweight_test.hpp>
|
||||
#include <sstream>
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
// Test public function subcontracting from middle branch of inheritance tree.
|
||||
|
||||
#include "basic.hpp"
|
||||
#include "smoke.hpp"
|
||||
#include <boost/detail/lightweight_test.hpp>
|
||||
#include <sstream>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user