The EGSnrc C++ class library is organized as a main library file (libegspp.so for Linux/Unix, egspp.dll for Windows, and libegspp.dylib for Mac OSX) and a series of small dynamic shared objects (DSO, also known as DLL in the Windows world), one for each geometry and source type. EGSnrc applications written in C++ link against the main library. Geometry and source DSOs are loaded dynamically as needed at run time using the EGS_Library class. In order this to work, each geometry DSO must provide a C-style function createGeometry(), which, given a definition of a geometry stored in an EGS_Input object, creates an instance of the geometry class. In a similar way each particle source DSO must provide a C-style function createSource() that can create instances of the particle source class provided by the DSO. The geometry and source of a simulation are specified in an input file. The input file is read in by an instance of the EGS_Input class and results in a tree-like structure of key-value pairs (for elementary properties) or keys and an arbitrary number of subkey-value pairs (for compound properties). The geometry information is stored in a compound property named geometry definition, the source information in a property named source definition. This input tree is then passed to a geometry factory, which, based on the values stored in certain sub-keys, loads the corresponding geometry DSO dynamically into memory and passes the necessary information to the geometry creation function of the library. In a similar way the information related to particle source is given to a source factory. The syntax of the input file is therefore an important part of the process of specifying a simulation geometry and/or particle source and is described more detail in the EGS_Input class documentation

There are several motivations behind this design:

Most of the time only a small subset of the provided geometry and source types are needed for a given simulation. It would therefore be wasteful to have all geometry and source classes loaded in memory as it would be the case with a single monolithic library. In addition, the larger the number of geometries and sources becomes, the more memory will be needed at run time
The user can easily extend the geometry and/or particle source packages by adding a geometry or source derived from the base geometry or base source classes. Such additional classes become immediately available for use in any EGSnrc application written in C++ when compiled into DSOs, without the need to recreate the main library and or the application.
Geometries and sources can be dynamically loaded by other applications, not just EGSnrc C++ applications. For instance, there is a geometry tester provided with the distribution, which uses the just described mechanism to dynamically construct a geometry object from the definition in an input file and can then perform a number of tests (this is very usefull when developing new geometries). The geometry viewer provided with the distribution also dynamically constructs the geometry to be visualized from the information stored in an inpout file.
It is planed to develop graphical user interfaces (GUI) for the definition of geometries, sources, simulation parameters, etc., for future versions of egspp. Such GUIs can easily store the information input by the user into instances of the EGS_Input class and then use the mechanism of dynamically creating geometry, sources, and possibly other classes needed by the simulation to construct the necessary objects and run the simulation.