
Hello all, N1962 does not indicate that contracts for volatile members should be handled in any special way (in fact, volatile is not discussed at all in N1962). My library does the following for volatile members: 1) The object `this` is const volatile (and not just const) while checking preconditions, postconditions, and invariants for a volatile member. 2) By default, class invariants of volatile members are the same as for non-volatile members. However, programmers can specify a different set of class invariants for volatile and non-volatile members if they wish to do so. The reason for 2) is that when programming a volatile member that overloads a non-volatile member, programmers can already specify a different set of preconditions and postconditions. Therefore, it seemed reasonable to give the option to also specify a different set of class invariants for volatile and non-volatile members (otherwise why would the pre/postcondition of a volatile member be different from the ones of its non-volatile version while the class invariants are forced to remain the same?). For example, consider a very strange number class which is non-negative (>= 0) when used in non-volatile context but it is non-positive (<= 0) when used in volatile context (probably not a real-life example but still...). The contracts could read: #include <contract.hpp> CONTRACT_CLASS( class (num) ) { CONTRACT_CLASS_INVARIANT( get() >= 0, // (1) volatile class( get() <= 0 ) // (2) ) public: CONTRACT_FUNCTION( public void (set) ( int x ) precondition( x >= 0 ) // 3) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public void (set) ( int x ) volatile precondition( x <= 0 ) // (4) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public int (get) ( void ) const ) { return x_; } CONTRACT_FUNCTION( public int (get) ( void ) const volatile ) { return x_; } num ( ) : x_(0) {} private: int x_; }; int main ( ) { num p; p.set(3); num volatile v; v.set(-3); return 0; } Note that via function overloading it is automatically possible to specify a different set of preconditions (and eventually postconditions) for the volatile member (4) than for the non-volatile member (5). Therefore, my library also allows to specify a different set of class invariants for volatile members (2) than for non-volatile members (1) so that the entire contract (including class invariants) can be programmed differently for volatile members if programmers wish to do so. However, if `volatile class(...)` is not used (default) the class invariants: CONTRACT_CLASS_INVARIANT( get() >= 0 ) are applied by the library to all members volatile and non-volatile. (In this case, this invariant is compiled in const volatile context iff the class has one or more volatile functions so a volatile verion of get() is only requirement if a volatile version of set() is introduced.) What do you think? Thanks, --Lorenzo