C++ code written in the HCL framework can be as clear and clean as traditional Ratfor code in the SEPlib framework. However, the two code formats are very distinct. The code of an operator's Image() method is comparable in both frameworks. Particularly, since HCL's vector accessor functions imitate the Fortran indexing. On the other hand, for loops prevail over do loops in C++ code. HCL programmers are tempted to implement recursive looping to accommodate data inputs of various dimensions in a single operator. Such recursive looping can clutter the operator's code and possibly slow down its execution. Because of its object orientation, HCL hides ugly I/O details in the various vector classes. Furthermore, the solver objects encapsulate the entire optimization code. Consequently, the main routines are very readable and expose the overall approach. Since the solvers exclusively use a limited set of standard vector and operator methods such as myvector.Add() or myop.Image(), the solvers are almost as readable as pseudo-code and expose, without clutter, interesting abstract concepts.
HCL's operator classes deal with constructing and checking of vector spaces (the operator's domain and range), which can be tedious. The traditional SEPlib code does not check vector space information.
Unfortunately, HCL's abstract base class concept requires a considerable amount of explicit type casts which inevitably clutter the HCL code. The casts are necessary to specify at compile time what objects are returned by a class that returns an abstract object. Without the cast the compiler will not know about any additional methods or members the concrete class carries.