Dr. Dobb's Journal February 1997
As an example of the different ways in which constraints on C++ programs may be expressed, consider our Rule 10. In English, the constraint is: "Make destructors virtual in base classes." When this constraint is formalized and made amenable to enforcement by computer, it quickly becomes more complicated.
CCEL offers a fairly succinct way to express this constraint, because CCEL was specifically designed to make the expression of constraints like this straightforward. Still, CCEL's formal nature makes it wordier than English. (It also makes it more precise.) Example 1 illustrates Rule 10 in CCEL.
CCEL embodies a declarative approach to the specification of constraints: You specify what you want to enforce, not how to enforce it. This CCEL constraint can be read like this: "For all classes B and all classes D that inherit from B, B must have a member function m such that m is a destructor and m is virtual."
Compared to CCEL, the programmable analysis tools we investigated are long winded. That's because they employ a procedural approach to constraint specification: You write code specifying how to go about detecting violations of the constraints you define. In practice, a procedural approach is more powerful, but it's also more complicated.
For example, Abraxas offers a C-like programming language for new constraints. HP's CodeAdvisor uses C++ as an extension language and new constraints are implemented via classes inheriting from the predefined Rule class. These classes are then compiled and linked to a run-time library. Centerline plans a similar extension of C++Expert.
Implementations of Rule 10 in all of these tools are available electronically (see "Availability," page 3).
-- S.M. and M.K.