HP 3000 Manuals HP 3000 Manuals
Step Four: Improve the Translated Source After following the first three steps in this chapter, you will be tempted to "leave well enough alone". Resist this temptation. Any program written initially in SPL, and translated more or less literally into HP C/XL according to these guidelines, is unlikely to be one which a proficient HP C/XL programmer would create directly. The SPL "heritage" will be apparent in the use of union declarations, old SPL equivalencing operations, awkward I/O functions, and so on. A frequent reason for equating variable names to arrays in SPL is to overcome the lack of any form of record or structure variables. Wherever possible, the use of union to emulate SPL equivalencing should be examined to determine if the HP C/XL struct declaration is more natural and appropriate. Because HP C/XL performs implicit type conversions during expression evaluation, many type cast operations (which required type conversion functions in SPL) may have been inserted in the converted program where they are no longer needed. In SPL, strings are simply ASCII characters in arrays of type BYTE. Various conventions were devised by SPL programmers to determine and store the length of these strings, such as keeping a count in a separate variable, or possibly within the first byte of the array. These same operations may be converted to HP C/XL, but the accepted convention in HP C/XL is to delimit a string by appending a NUL character to the string. A NUL character (numeric value 0) is represented in HP C/XL by "'\0'". Once you adopt this convention, a large library of string manipulation routines becomes available, both simplifying and optimizing string operations. The wide range of formatted I/O routines available in HP C/XL may be utilized, frequently allowing many SPL operations to be replaced with a simple function call. At first, the HP C/XL I/O functions may look simple, and therefore limited. However, the generality of these functions means that they may be combined in ways that are just as powerful as system intrinsics with seemingly more complex options. Remember that reliance on any specific operating system intrinsics restricts the program to that operating system. While this may be unavoidable in some cases, the use of the HP C/XL high level I/O functions will increase program portability, even across operating systems. Storage allocation (and deallocation) in SPL is quite straightforward, but restrictive. In HP C/XL, a compound statement may contain local variable declarations that are allocated on entry to the statement and released when it ends. There may be instances in a program translated from SPL where this is a more natural structure for the program. It can simplify the source code by defining the scope of specific local variables better. Also in HP C/XL, there are several functions which allow programmatic allocation and deallocation of storage at runtime. No similar features are easily available to the SPL programmer, leading to the occasional clumsy use of dynamic arrays within procedures declared only to allocate space dynamically, or worse, to manipulate hardware registers to force access to memory regions not otherwise available. Use of HP C/XL functions such as malloc, realloc, and free makes it possible to dynamically allocate, reallocate, and release storage at will. HP C/XL programs need not retain the SPL "flavor" that results from a literal translation. The features and operations that performed very efficiently under MPE V now may be needlessly complex and quite possibly less efficient. By using the high level constructs of HP C/XL and its extensive library functions, you can develop programs that are maintainable, portable, and will result in extremely efficient runtime code with the optimizing features of the HP C/XL compiler.