LLOOP Generated Code Reference

The generated source code splits into the categories listed below. The source files generated from the ini.gsp spec file (see Ini file parser example) are used to illustrate it.

Click on a namespace to browse the classes defined there.

The application classes are all specific classes which are generated from the input gsp specification file(s). Their definitions and interfaces depend partly on the specification provided in the gsp spec file(s).

The namespace where an application class is defined in is the name of the gsp file, without extension, from which the class was generated.

The most interesting class is the Parser Class to be used to carry out the parsing according to the input gsp spec file(s). This class is always named Parser.

There is a class generated for each symbol (non-terminal and token), either defined in or imported from the gsp file(s). The class name is that of the symbol.

These are the predefined base classes which the Application Classes derive from. These classes provide the base infrastructure common to all generated parsers. Their definitions and interfaces are fix and predefined.

These classes are defined in the predefined namespace gsp. Among the most important are the following:

• the base LLParser class which all application-specific Parser classes inherit from.
• the base Symbol class which all token and non-terminal classes inherit from.
• the base Visitor class. The visitor class is intended to be derived for implementing specific post-processing on the object tree obtained from the parsing.
• the Expander and the Backtracer are good examples of visitor implementations. The generated code relies on them to implement respectively the expanding and backtracing functions.

Beside the framework base classes, there are also some reusable, self-dependent, cross-platform components which the generated code and some standard token implementations depend on. These classes are defined in the universal namespace. There are self-dependent and are not tied to the generator. The String class is notably thoroughly used in all standard symbol implementations

It is important to note that, even though used by the generated code and the standard token library, it is not mandatory to use these classes to implement a token or any other symbol. Token classes may inherit from other components, like the string class of the standard C++ library, to store and process read data.

Files Management

The generator ensures that files are removed when they become obsolete after a new generation.

Class Files

For C++, there is a header (.h) file and an implementation (.cpp) file generated for all classes. The file names, without extension, are composed of the name space of the class followed by " __ " and the actual name of class.

If no name space is specified, the file name is just the class name followed by the file extension.

Makefiles

There is a makefile generated for the global generation project. This makefile allows to construct the executable or library using the source code files generated from all input gsp files. Its name is Makefile for UNIX systems and NMakefile for Windows systems.

Beside, there is a makefile generated independently for each input gsp file. Such a makefile allows to build an executable or library using the source code files generated only from the matching gsp file. Its name is the base gsp file name followed by the extension .mak for UNIX systems and .nmak for Windows systems.

Main Programs

There is a main program generated for the global project. Its name is main.cpp. This program is compiled by the global makefile if the construction of an executable is requested.

There is also a main program generated for each individual input gsp file. This file is named following the same convention as for application classes, except that main is used instead of a class name (see above). These main programs are not compiled by the global makefile, but only by the gsp file-specific makefiles.

All main programs have a default implementation which consists of creating an instance of the parser class and using it to parse the file whose name is passed as argument to the program. If the keyword selftest is used, the selftest of all generated symbols is carried out instead. On failure, it displays the syntax error encountered. On success, it expands the parsed root object onto the standard output so that the user can check visually whether what has been parsed matches the content of the original input file.

Main programs are never overwritten. A user is free to change and customise them. To force re-generation, these files must simply be removed.

Global Header Files

For each input gsp file, there is a global header file which allows to include in one step all header files generated from that gsp file.

Its name is composed of the gsp file base name followed by "__", again the gsp file base name, "_" and finally the fix string "headers".

Framework Files

There are also other files generated not part of the generated code and described here for information.

Generation Management Files

The following plain text file are generated within the .gspc directory:

• list_h.txt: paths of the C++ header files generated relatively to the generation directory
• list_cpp.txt: paths of the C++ implementation files generated relatively to the generation directory
• list_tcl.txt: paths of the TCL/TK script files generated relatively to the generation directory
• list_other.txt: paths of any other file (makefiles...) generated relatively to the generation directory
• gspc.cfg: configuration parameters used during last generation

These files shall never be modified manually. They are used internally by the generator to manage differences between successive code generation.

Framework Runtime Statistic File

When running a parsing, a statistic file is created for each gsp file. This file gives the number of instances created for each token and non-terminal. The name of this file starts with a dot, followed by the gsp file base name, and ends with "_stats".

The files generated from the ini.gsp spec file (see Ini file parser example) are the following:

ini.mak
ini.nmak
Makefile
NMakefile

./include:

gsp__LLParser.h
gsp__Symbol.h
gsp__Visitor.h
ini__BlockToken.h
ini___ConstChoice_0.h
ini__DataList.h
ini__IdToken.h
ini__ini_comment.h
ini__ini_headers.h
ini__main.h
ini__Parser.h
ini__SectionList.h
ini__SIniFile.h
main.h
universal__File.h
universal.h
universal__Numeric.h
universal__String.h

./src:

gsp__LLParser.cpp
gsp__Symbol.cpp
gsp__Visitor.cpp
ini__BlockToken.cpp
ini___ConstChoice_0.cpp
ini__DataList.cpp
ini__IdToken.cpp
ini__ini_comment.cpp
ini__main.cpp
ini__Parser.cpp
ini__SectionList.cpp
ini__SIniFile.cpp
main.cpp
universal.cpp
universal__File.cpp
universal__Numeric.cpp
universal__String.cpp