|
|
|
|
General Information
Tutorials
Reference Manuals
Libraries
Translation Tasks
Tools
Administration
|
|
Library Reference
Using Frame Modules
The library modules described in this manual are implemented directly in C.
These modules may export constants, variables and routines to their
clients.
To reduce overhead, these modules have been pre-compiled and stored in the
frame.
Frame modules need not be instantiated, although it is allowable to do so.
A frame module will be incorporated into a specification whenever anything
exported by that module is used in the specification.
If a frame module is instantiated by a specification, however, it will be
included regardless of whether any exported facilities are used.
In either case, source code for the module is included in the Each module is associated with a header file that specifies the interface it presents to its clients. Any module requiring access to the exports of another module must include the header file associated with the exporting module. Library header files are written according to certain conventions. We recommend strongly that you follow the same conventions when defining code modules to carry out tasks specific to your problem. Your header files will be included in generated modules, and Eli will make the same assumptions about them that it does about header files from the library. Failure to follow these conventions may result in errors when the generated programs are compiled. Since you will not recognize the generated programs, such errors may be difficult to diagnose.
Conventions for writing interfacesBy convention, every header file is complete: Including a module's header file in a C program provides all of the information needed to use that module. For example, the environment module exports operations that deliver definition table keys as their results. In order to use the environment module, therefore, a client must have access to the interface of the definition table module. Our convention therefore requires that the header file for the environment module include the header file for the definition table module. If the environment module header file did not include the definition table module header file, a C program that included that included the environment module header file would not necessarily have all of the information needed to use the environment module. This convention greatly simplifies decisions about which header files to include, and avoids all questions of the order in which header files should be included. It does, however, require that each header file be protected against multiple inclusion. Protection is provided by defining a symbol in each header file and skipping the entire contents if that symbol is already defined. The symbol is the name of the header file, given as upper-case characters with any periods replaced by underscores.
Example of a header fileHere is an excerpt from `envmod.h', the header file for the environment module:
#ifndef ENVMOD_H #define ENVMOD_H #include "deftbl.h" typedef struct EnvImpl *Environment; /* Set of Identifier/Definition pairs */ ... /***/ #if defined(__cplusplus) || defined(__STDC__) extern DefTableKey DefineIdn(Environment env, int idn); #else extern DefTableKey DefineIdn(); #endif /* Define an identifier in a scope * If idn is defined in env then on exit- * DefineIdn=key for idn in env * Else let n be a previously-unused definition table key * Then on exit- * DefineIdn=n * idn is defined in env with the key n ***/ ... #endif
Protection against multiple inclusion is provided by the test of
|
