Another Mediocre Assertion Mechanism for C++

Transcription

1 Another Mediocre Assertion Mechanism for C++ Pedro Guerreiro Departamento de Informática Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa P Caparica, Portugal pg@di.fct.unl.pt Copyright notice This paper will be published in??? (ed), Proceedings TOOLS 33, IEEE The material is 2000 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

2 Another Mediocre Assertion Mechanism for C++ Pedro Guerreiro Departamento de Informática Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa P Caparica, Portugal pg@di.fct.unl.pt Abstract Assertions are a basic programming ingredient. If the language you use does not support them in a proper way, at least you must use some kind of standardized comments, to express things like preconditions for functions. The comments can be turned into executable functions by a preprocessor, but we could write the function calls directly, with the advantage of having the compiler check their syntax. This technique can be used with C++, to emulate the full set of assertions used in Eiffel to implement Design by Contract. The assertion functions are grouped in a class, class Assertions, which is inherited by the classes whose functions we want to assert. The assertions can be turned on and off object by object, during the execution of the program. The system works well under inheritance, although some guidelines must be followed when writing postconditions on the base class. The simplicity of this mechanism makes it possible to comment out all or some of the assertions automatically, through the programming environment. 1. Introduction It used to be a common programming technique to emulate programming constructs absent from the language you were using. For example, Fortran IV did not have while loops. If you wanted to do structured programming in Fortran IV, you would emulate while loops by a clever systematic pattern (did I say pattern?) of one IF, two GOTO and one CONTINUE. In COBOL, we could consider paragraphs as procedures, but they are parameterless. If you wanted to pass arguments to a paragraph, you would put aside some working storage variables to do the communication between caller and callee. If you are using ANSI C and you want to program object-orientedly, you will design your program around types defined as structures, together with the functions that operate on those structures. These emulations are always mediocre, when compared with the original, but we cannot forsake our language of decades just because a new language introduces an idea that we fancy. If you have been happy with Pascal for the last 25 years, you are not going to switch to Java for your text processing applications just because Java comes with a Tokenizer class that helps that kind of job [1]. Instead, you emulate the concept in Pascal, and go on with your work, as usual. Assertions like the ones we find in Eiffel are a fundamental programming concept, and a tool that we cannot do without for expressing, in the program text, logical properties of the program [5, 7, 8, 9]. If your language, or your programming environment, does not behave like Eiffel in that respect, then, at least, you should express those properties as comments. The intention is good, but comments are comments, their syntax is not checked, it is easy to forget to update them, and in the end this can cause some confusion.

3 A more serious technique is to use formal comments, that can be handled by a preprocessor, and generate executable instructions to be used for catching bugs while the program is being developed [3, 6]. Another technique is to use a set of macros working together with a given debugger [4]. These are laudable approaches, but sophisticated ones, and their first drawback is that they cannot be taught to novices in programming. Indeed, they involve tools and concepts foreign to the language (the syntax of the comments, the preprocessor, the debugger), and affect, to some degree, the sharpness of the assertion mechanism. On the other hand, assertions are not something to be added after the program is written: they are a part of the design process, and should be present in the very first programs students have to study or to write. We could also impose the discipline of accompanying each function m in a class by two assertion functions m_pre and m_post, and then have m call m_pre upon entry and m_post upon exit, in such a way that m would fail (raise an exception) when those functions return false. In m_pre we would program the precondition for m, and in m_post the postcondition. Actually, this is the technique used by the jcontractor library for Java, which takes advantage of Java reflection, for automatically doing the instrumentation the original methods with the provided assertions [2]. The system we designed came from the need to teach Design by Contract [7, 8] to students who do not have an Eiffel environment to work with, but are knowledgeable in C++ [11]. In order to do something meaningful, students will have to use preconditions, postconditions, invariants, in their C++ programs, for specification purposes, for implementing Design by Contract, and for catching bugs. Using the preprocessor approach was out of the question, for it would be a giant step backwards: we simply do not want to have our programs go through another preprocessor prior to being submitted to the compiler. Even if the process was fully automatic and fast, then, when writing a program, we would have to deal with errors from the preprocessor and errors from the compiler, not a pleasant prospect at all. Using the macro approach was also unthinkable: after practicing with C++ for some years, we lost the touch to handle those elaborate macro techniques. In fact, one of the good things about C++ is that it downplays the importance of macros in programming. We do not want to have to rely on them for such a noble cause. So the assertion mechanism had to come from within the language. This approach makes it intrinsically portable, and we will be able to use it in any environment. Furthermore, if the design is simple it can be adapted to other similar languages. The goals of this emulation are modest: the full set of Eiffel assertions should be available, the assertions are executable; they can be turned on and off during execution; the program should be able to recover from an assertion that failed; we must be able to cut, or comment out, all the programming text related to assertions (in order to produce a clean version), and paste it back, in the same locations (even if the clean text was edited); no other data members or functions must be added to the classes for helping the mechanism; the mechanism should work in the presence of inheritance; the old notation must be available for postconditions; clever use of C++ is allowed (exceptions, multiple inheritance, template classes, STL), but no low-level gadgets (no macros, no pointers to functions, no meddling with the type system). After this introduction to the problem and this discussion of design goals for the mechanism, we start by presenting its preconditions, postconditions and invariants. The first version does not use the old notation, which we then introduce in a second stage. With the mechanism we fully specify a generic bounded stack. Then we consider loop variants and invariants, and we exemplify with Euclid s algorithm for the greatest common divisor. We end up by

4 analyzing what happens under inheritance, using two classes for simple bank accounts. The difficulties with inheritance are not solved by the mechanism, but by methodology. 2. Preconditions, postconditions, invariants Let us consider a generic bounded stack, as it could be implemented in C++, with an internal array: template <class T> class Stack private: int _capacity; int _count; T *_items; Stack(int capacity) // Constructor _capacity = capacity; _count = 0; _items = new T[capacity]; virtual ~Stack() // Destructor delete [] _items; virtual int count() const // Number of elements return _count; virtual bool empty() const // Are there no elements? return _count == 0; virtual bool full() const // Is representation full? return _count == _capacity; virtual const T& item() const // Top element return _items[_count-1]; virtual void put(const T& x) // Add x on top _items[_count] = x; _count++; virtual void remove() // Remove top element _count--; ; Please note our conventions: all data members are private and their names start with an underline. The corresponding getters use the same name without the underline. (In this example we do not have any setters, whose names would have the prefix set.) All functions are virtual, just like it happens implicitly in Eiffel or Java. Functions (other than constructors and destructor) are either selectors, i.e., const functions returning a value, or modifiers, i.e., nonconst functions returning void. Class arguments and results are passed by const reference. There are no pointers in the interface. All functions are declared and defined in the same file. This is a header file, and there is no need for the source file. Indeed, there will be only one source file in the program: the file that contains the main function. (No, this is not the most common C++ style ) Consider, for example, function put: it has a precondition that the stack must not be full, and a postcondition that the stack is not empty, and that the top element is the element just added to the stack [8]. We could specify this using comments: virtual void put(const T& x) // Add x on top // pre!full(); _items[_count] = x;

5 _count++; // post!empty() && item() == x; This only makes sense when the effective generic parameter used for type T has the == operator. The comments are formal, and we could imagine an automatic system capable of translating them into executable functions. In an object oriented architecture, these would have to be functions from some class. On the other hand, if we have the functions, there is no need to go through the comments: we can understand pre(!full()), a function call, just like we understand the comment, with the benefit that the compiler checks it. An additional benefit is that it is executable, and can raise an exception when the argument is false. Let Assertions be the class for our assertion functions. In the Eiffel tradition we will use require and ensure instead of pre and post. Functions from this class must be able to raise exceptions, so the class declares its own exception type. When an exception is raised, we can use its associated string to give some information to the client. For making it flexible, we shall let each assertion have a second optional argument representing the label of the assertion, which will be added to the exception text. Assertions may be turned on and off, therefore there must be a boolean data member for representing that on-off state. Here is a first sketch of the class: class Assertions class Exception: public std::exception Exception(const std::string& label): exception (("Assertion violation: " + label + ".").c_str()); ; private: bool _enabled; Assertions() // Constructor. _enabled = true; virtual void assertions_enable(bool b) // Turn assertions on and off. _enabled = b; virtual void require(const std::string& label, bool b) const // Preconditions. if (_enabled &&!b) throw Assertions::Exception("require " + label); void ensure(const std::string& label, bool b) const // Postconditions. if (_enabled &&!b) throw Assertions::Exception("ensure " + label); ;

6 In order to make these functions available to class Stack, we make Stack inherit from Assertions: template <class T> class Stack: public Assertions ; We can now properly program function put, using assertions: virtual void put(const T& x) // Add x on top. require(!full(), "not full"); _items[_count] = x; _count++; ensure(!empty(), "not empty"); ensure(item() == x, "top element"); As of now, functions require and ensure are the same, except for the text they add on their own to the label. However, ensure must perform an important extra task: checking the class invariant. A class invariant is a condition that holds for all objects of that class, immediately after construction, and at all subsequent times, except when an object is being modified by a function. The class invariant for class Stack is implemented as function invariant, redefining the one inherited from Assertions. Here is the scheme: In class Assertions: virtual bool invariant() const // Default invariant. return true; void ensure(bool b, const std::string& label = "") const // Postconditions. if (_enabled &&!b) throw Assertions::Exception("ensure " + label); if (_enabled &&!invariant()) throw Assertions::Exception("invariant " + label); Class Stack has the following invariant: virtual bool invariant() const // Stack invariant. return 0 <= count() && count() <= capacity(); The invariant is systematically checked at all postconditions. This means that in function put the same condition is checked twice. If we think this should be avoided, we can merge the conditions in the two ensure calls, at the cost of losing precision in the labels. In the general case, invariants must also be checked in preconditions. However, our convention that all class arguments are passed by const reference avoids the indirect invariant effect [8], through which an operation on an object may invalidate an invariant in another. In our case, the only way to change the value of an object is by calling a modifier on that object. Therefore, invariants need to be checked only upon exit from modifiers.

7 The invariant must be verified after construction and after each modifier. Thus, each constructor and each modifier should have a postcondition. Here is the stack constructor, fully asserted: Stack(int n) // Constructor. require(n > 0, "capacity is positive"); _capacity = n; _count = 0; _items = new T[n]; ensure(capacity() == n, "capacity set"); ensure(empty(), "initially empty"); ensure(_items!= 0, "representation set"); You may notice that the last postcondition is for the benefit of the class writer only: it deals with internal representation of stacks, which should be of no concern to clients [8]. 3. Postconditions in selectors The ensure assertion is not appropriate for selectors because in these cases it is not necessary to check the invariant, and, also, more trivially, because the ensure assertion, which is typically placed at the end of the function, is useless after the function s return statement. For selectors, we need an assertion on the value of the function, after it was computed, but before the function returns it. We use a different assertion, satisfy, for this: virtual void satisfy(bool b, const std::string& label = "") const if (_enabled &&!b) throw Assertions::Exception("satisfy " + label); This requires a particular style of programming, borrowed from Eiffel, in which the result of the function is computed into a local variable result, which is then returned in the last statement of the function. Here are two examples: virtual bool empty() const // Are there no elements? bool result = _count == 0; satisfy(result == (count() == 0), "empty result"); return result; virtual bool full() const // Is representation full? bool result = _count == _capacity; satisfy(result == (count() == capacity()), "full result"); return result; These postconditions can be seen as particular cases of class invariants, stating that empty() == (count() == 0) and that full() == (count() == capacity()). Selectors which merely return the value of a private data member need no postconditions, and they can be understood as proxies of the value of the data member. These selectors are necessary in C++, and unnecessary in Eiffel.

8 4. Checking arbitrary conditions The assertions we have seen so far are used for special purposes: preconditions and postconditions. If we want to assert that an arbitrary property holds at a certain point in the program text, we use assertion check: virtual void check(bool b, const std::string& label = "") const if (_enabled &&!b) throw Assertions::Exception("check " + label); This assertion is very similar to satisfy and to require. We could live with only one of them, if we forsake the information provided to the exception message. However, the idea is that we can straightforwardly refine this mechanism in order to turn on and off assertions of a given category. We do not pursue that here, in order not to burden the presentation with several different _enableds, one for each assertion: _enabled_require, _enabled_ensure, _enabled_check, etc. 5. The old notation The old mechanism is used to compare the value of an attribute after the operation of a modifier with the initial value of that attribute. There are no miracles here: either we do some preprocessing to discover that the initial value of a given attribute is mentioned in a postcondition, or we declare that ourselves in the program. Our system, which does not do any preprocessing, uses the function observe for that. By observing an attribute we store its value together with a key. Later we can retrieve it using the function old. Let us see how functions observe and old are used in function put: virtual void put(const T& x) // Add x on top. require(!full(), "not full"); observe("count", count()); _items[_count] = x; _count++; ensure(!empty(), "not empty"); ensure(item() == x, "top element"); ensure(count() == old("count") + 1, "count was incremented"); For implementing observe and old we use class map from the standard template library, STL [10]. Class Assertions now has a second data member, a map: class Assertions private: bool _enabled; std::map<const std::string, int> _old; ; This implementation is simple, but it limits us to observe integers only. Here are the functions: virtual void observe(const std::string& tag, const int& x)

9 _old[tag] = x; virtual int old(const std::string& tag) return _old[tag]; Were it not for STL, this would require a lot of work. The fact that this old mechanism can only handle integers is a serious limitation, of course. To be able to contemplate other types, we can either have a map for each type (no, we do not want that!) or use a polymorphic map. This polymorphic map approach looks promising, and we are currently working on it. 6. Loop invariants and variants The invariants we saw were class invariants, that are supposed to hold after construction and after each modifier. We should also consider loop invariants, that hold after each step in a repetitive process. The idea is that if the invariant holds before the loop, and each step of the loop does not destroy it, then, if the loop ever terminates, it will terminate in a state where the invariant holds. The invariant is just a condition, and we could check it with assertion check. However, for clarity, we introduce another assertion, loop_invariant: virtual void loop_invariant(bool b, const std::string& label = "") const if (_enabled &&!b) throw Assertions::Exception("loop invariant " + label); In order to guarantee that the loop terminates, we can use a variant function, i.e., an integer function such that its values strictly decrease at each step in the loop, but always remain nonnegative. If such a function exists the loop must terminate. For implementing function loop_variant, which will fail if the variant function does not decrease, or if it becomes negative, we use the map. The first call to loop_variant installs the initial value, the subsequent calls compare and update the value stored in the map: virtual void loop_variant(const std::string& tag, int n) const Assertions* that = const_cast<assertions*>(this); if (_enabled) if (0 <= n && (_old.count(tag) == 0 n < that->_old[tag])) that->_old[tag] = n; else throw Assertions::Exception("variant " + tag); Note that loop_variant must be a const function, even though it must change the representation. This is because, unlike observe and old which are only used for modifiers, loop_variant may be used for selectors, which are declared const, and are not allowed to modify their objects. This is the reason why we have to throw away the constness of the map. Assertion loop_variant should be placed before the iterated statement, where it will be checked before each step. It is true that the very last step may not decrease the variant, and yet there is no failure, because the loop will have terminated. However, if the loop is entered again, the last value from the previous execution would still be stored, and that would disrupt

10 the process. This shows that we must be careful to release the variant tag, so that it will not be present in the map the next time. Here is function release, doing just that: virtual void release(const std::string& tag) const const_cast<assertions*>(this)->_old.erase(tag); The standard example for loop invariants is Euclid s algorithm for the greatest common divisor [8]. With our assertion mechanism, it looks like this: class Euclid: public Assertions virtual int greatest_common_divisor(int a, int b) const require(a > 0 && b > 0, "arguments positive"); int x = a; int y = b; loop_invariant(x > 0 && y > 0, "loop invariant"); loop_invariant(true, "if d divides x and y, d divides a and b"); while (x!= y) loop_variant("gcd loop variant", x + y); if (x < y) y -= x; else x -= y; loop_invariant(x > 0 && y > 0, "loop invariant"); loop_invariant(true, "if d divides x and y, d divides a and b"); release("gcd loop variant"); check(x == y, "values are equal"); int result = x; return result; ; Note the second loop invariant in each case. With a true condition, it functions just like a comment. 7. Inheritance In order to investigate what happens to preconditions and postconditions under inheritance let us consider the standard example: a class Account, representing simple bank accounts with which you can deposit and withdraw amounts of money, and a derived class, more specialized. Here is class Account, with our assertions in place: class Account: protected Assertions private: std::string _client; int _balance; int _minimal_balance; Account(const std::string name, int deposit) // Constructor. require(deposit > 0 && deposit >= minimal_balance(), "initial amount"); _client = name; _balance = deposit;

11 _minimal_balance = 20; ensure(client() == name && balance() == deposit, "construction ok"); virtual const std::string& client() const // Client of the account. return _client; virtual int balance() const // Balance of the account. return _balance; virtual int minimal_balance() const // Minimal balance allowed. return _minimal_balance; virtual void deposit(int amount) // Deposit amount in the account. require(amount > 0, "amount is positive"); observe("balance", balance()); _balance = _balance + amount; ensure(balance() == old("balance") + amount, "balance is now greater"); virtual void withdraw(int amount) // Withdraw amount from the account. require(amount > 0, "amount is positive"); require(balance() - amount >= minimal_balance(), "withdrawal is possible"); observe("balance", balance()); _balance = _balance - amount; ensure(balance() == old("balance") - amount, "balance is now smaller"); virtual bool invariant() const return balance() >= minimal_balance(); ; Class AccountDetailed stores all operations in two lists: a list for deposits and a list for withdrawals. Let us concentrate on the constructor and one of the modifiers, deposit: class AccountDetailed: public Account private: std::list<int> deposits; std::list<int> withdrawals; AccountDetailed(const std::string name, int deposit): // Constructor. Account(name, deposit), deposits(), withdrawals() deposits.push_front(deposit); ensure(deposits.size() == 1 && withdrawals.empty(), "construction derived ok"); virtual void deposit(int amount) // Deposit amount in the account.

12 Account::deposit(amount); observe("deposits size", deposits.size()); observe("sum deposits", sum_deposits()); deposits.push_front(amount); ensure(deposits.size() == old("deposits size") + 1, "deposit size ok"); ensure(sum_deposits() == old("sum deposits") + amount, "sum deposits"); virtual bool invariant() const return Account::invariant() && sum_deposits() - sum_withdrawals() == balance() && count_operations() == count_deposits() + count_withdrawals(); ; Function deposit first calls the base function, as usual in these situations. Is this OK? Within the base call, the precondition will be evaluated, and this causes no problem, because the precondition for the derived class must be the same. In fact, applying Design by Contract, the precondition for a redefined function may be more liberal, but not less liberal, than the original. However, in our system we have no direct way of weakening the precondition, and so, the precondition must be the same. Note that we have no explicit require in the redefined function. If we had, we would be strengthening the preconditions, against the rules of Design by Contract. After the base class function is called, its postcondition is evaluated. The precondition may involve polymorphically functions from the derived class. In this example it does not do that directly, but it does it through the invariant. Here the situation is dangerous: the base class object has been modified, but the complete derived object has not: the call to the invariant at this point is meaningless, and it may fail because the object has not been fully modified yet. Actually, that is what happen with the previous program. Once the problem is identified, the solution is obvious: one must not evaluate the postcondition on the full object, but only on the base class object. Since the postcondition is called from the base class, it s the base class we must change: virtual void deposit(int amount) // Deposit amount in the account. require(amount > 0, "amount is positive"); observe("balance", balance()); _balance = _balance + amount; Account(*this).ensure(balance() == old("balance") + amount, "balance is now greater"); The technique is to create a temporary copy of the object, guaranteed to be of the base class, and evaluate the postcondition on this object. Note that this phenomenon does not happen with the constructor. The postcondition in the base class constructor called for an object of the base class, always, and no polymorphism is involved. This example and the discussion show that our assertion mechanism can also be used with inheritance, provided the preconditions are the same in the redefined functions, and the postconditions on the base class are explicitly computed on objects of the base class. If we really need a different precondition for a redefined function then we should define the precondition as a member function of the base class, and redefine it, either more liberally or more strictly,

13 in the derived class. We then use this member function in the require calls in both the base class and the derived class, effectively making it the same, to the eyes of the assertion mechanism. This corresponds to the idea of an abstract precondition [8]. According to Design by Contract, postconditions in derived classes can only be more strict than the corresponding ones in the base class. This is the standard behavior of our system: calls of ensure for modifiers in derived classes reinforce the calls already made for the base class object. 8. Conclusion If you do not have a dog, you go hunting with a cat. C++ does not come equipped with an assertion mechanism, but the one we designed works quite well, and can be installed (and learned) quickly. With it we can implement Design by Contract on a meaningful basis, using as assertion language the boolean expressions offered by C++. The mechanism is simple and light: it can be used for some of the classes in our program, and does not penalize the others. It can be toggled an object by object basis, even during program execution. Switching it off will not speed the program dramatically, however, because the arguments of the assertions will still be evaluated. And, if they are evaluated, we may as well let them perform their mission to the end However, if you want more control, you can modify the system so that a set of switches allow to turn on and off all assertions of a given category. On the other hand, it is a simple programming exercise to comment out the assertions, selectively if necessary. If we comment out all the assertions, there will be absolutely no overhead left from the assertion mechanism to slow down the execution. Furthermore, if you think the comments obfuscate the program, they can be erased automatically, or erased and kept in a separate file for later reinsertion. The simplicity of the scheme makes all this possible. The mechanism does not have the elegance of Eiffel, nor does it offer all its facilities ( old for integers only is not much, preconditions in base classes in the presence of inheritance are a bit clumsy) but it can be an acceptable compromise, and a useful vehicle to introduce the ideas of Design by Contract to a wider audience. It is quite unlikely that C++ will evolve to incorporate an assertion mechanism like Eiffel s. It is less unlikely that such a mechanism be provided by the programming environment. Some of the ideas briefly discussed here may have a role in that context. References [1] Arnold K and J Gosling, The Java Programming Language, Addison-Wesley, Reading (Mass.),1996. [2] Karaorman M, U Hölzle and J Bruno, jcontractor: A Reflective Java Library to Support Design By Contract, Technical Report TRCS98-31, Department of Computer Science, University of California, Santa Barbara, CA [3] Kramer R, icontract The Java Design by Contract Tool, Proc. of TOOLS 98, Santa Barbara, CA August 1998., pp [4] Maker P J, [5] McKim J, Programming By Contract: Designing for Correctness, Journal of Object Oriented Programming, May [6] Meemken D, [7] Meyer B, Eiffel, the Language, Prentice-Hall, New York, [8] Meyer B, Object-Oriented Software Construction, Second Edition, Prentice-Hall, Upper Saddle River (New Jersey), [9] Mitchell R and J McKim, Extending a Method of Devising Software Contracts, Proceedings TOOLS 32, IEEE [10] Musser D and A Saini, STL Tutorial and Reference Guide, Addison-Wesley, Reading (Mass.), [11] Stroustrup B: The C++ Programming Language, Third Edition, Addison-Wesley, Reading (Mass.), 1997.