previous up next print clean
Next: Acknowledgments Up: Schroeder & Schwab: RGF Previous: DOT PRODUCT TEST OF

CONCLUSIONS

We believe that all (or most) classes in HCL should be derived from a single generic class, HCL_Object. This could help enforce a similar format for the Inspect() method, which display the attributes of an object. Additionally, we might in the future want some other general functionality. Since no such base class exists in HCL, we created SEP_Object. Unfortunately, this required the use of multiple inheritance. We would not need multiple inheritance if HCL provided a general base class. HCL rejects multiple inheritance, since it can be unreliable and difficult to use in C++. Each SEP_Object includes a name and a description and the method SEP_Inspect(), which outputs descriptive information about the object. In this way, all objects derived from SEP_Object are guaranteed to have the SEP_Inspect() method. This helps to enforce a system with diagnostic, and therefore, debugging, tools.

In addition to a generic base class, we hope a future version of HCL will include Gaxpy() and Residual() methods for linear operators. The gaxpy (general alpha x plus y) operation applies an operator, , in the fashion . Likewise, the residual is calculated as . Both of these calculations are often used in solvers and are usually capable of being coded to run faster than simply applying the operator and adding (or subtracting) a vector. In the worst case, the trivial implementation of applying the operator and adding could be inherited from a base operator class.

From our experience, HCL is powerful in its simplicity and well designed. A few aspects of C++, however, make it more difficult to use. As much as we have used pointers through the years, they are often a little tricky and they usually make code less readable. Furthermore, although the const specification for parameters in C++ allows the compiler to make certain optimizations, we find that worrying about exactly when to use it can be a nuisance. In summary, we believe that the HCL framework, because of its abstraction, allows us to write modular code which functions as ``interchangeable parts'' in a way which previous systems do not.


previous up next print clean
Next: Acknowledgments Up: Schroeder & Schwab: RGF Previous: DOT PRODUCT TEST OF
Stanford Exploration Project
11/11/1997