Most of the core functionality is exported by the modules in the directory libcdg
, which can be viewed as yet another C library, although a very specialized one. Application-specific functionality must be implemented by the application that uses the libcdg
library. Thus, the command-line parser cdgp
includes code to parse its command-line options and to do I/O on a terminal, and the graphical parser xcdg
defines extensive routines to display input structures graphically. This document will eventually cover all data structures and functions of the constraint parsing library libcdg
and the text-based parser cdgp
.
CDG
is written entirely in C (and automatically generated C in some cases). It relies on several non-ANSI extensions to the C programming language (such as local functions and dynamic arrays). The GNU C compiler can compile all of these features; others may or may not.
CDG
library is organized into several modules each of which offers a specialized service to the environment. The set of all modules can be further divided into those offering the basic infrastructure for CDG
parsing whereas others are build on top and offer the different parsing flavours that are available.CDG
library.CDG
scripting interface.CDG
is implemented, the ConstraintNet.<moduleName>
.h and an implementation part <moduleName>
.c . Another module can use the exported services of this modules by including its declarations in <moduleName>
.h . Note that many of the functions covered in this manual are not exported and therefore cannot be used from other modules at all. The files skel.c
and skel.h provide a skeleton for a new module.libcdg
library explicitly use variable-length argument lists, other have a prototype like the following: int no, char **args
In this case it is always assumed that args is an array of valid zero-terminated strings, and that no specifies the number of these strings. This is an alternate way of passing a varying number of additional arguments. The strings contained in the array are called command words in this document to distinguish them from the actual function arguments.
To avoid the explicit use of pointer variables, most modules export typedef
'd aliases for all pointer types. These aliases have meaningful names, while the underlying struct
types have names ending in Struct:
typedef struct { String id; Boolean active; int counter; } SectionStruct; typedef SectionStruct *Section;
Although ANSI C allows the programmer to collapse these two typedef
statements into one, this construct cannot be parsed by the interface generator SWIG, used for building xcdg
. Therefore it is important to use exactly this way of defining pointers to structures.
One consequence of this definition style is that although very few pointer symbols are used in the code, most libcdg
data types obey reference semantics: A function called on a variable s
can usually change the underlying structure, even though C function calls actually use value semantics.
A more practical demonstration of the coding style is given in Skel - A Skeleton Module.