Dynamic loading

Views provides libraries in two formats: static (in the directories called stat* or static*) and dynamic (in the directories called dll* or shared*).

Although the mechanism and constraints described in this section apply in all situations, a major constraint can be relaxed when using dynamically-linked applications. In the case of a dynamically-linked application, Views can dynamically load a class that is not explicitly referred to by the application. If Views cannot properly locate the deserialization constructor when reading an ilv data file (that is, the indicated class header file has not been included by the application source files, so the class registration was not performed), then the core libraries search the imd files in the system path to find the module that holds the class. If Views finds the class, it loads the whole dynamic library to create the requested class instance.

Modules are dynamic libraries that hold the code that implements the functionality exposed by classes. The file name extension used by modules is the usual system file name extension for dynamic libraries (.dll, .so*, .a, or .sl, depending on the execution operating system). Modules files are, in addition, accompanied by an .imd file that lists, in a proprietary XML syntax, the classes that this module actually implements.

Nearly every Views library is a dynamic module, so the classes the modules implement can be dynamically located at runtime. To load classes without having to explicitly refer to them at build time, make sure that:

• The application is dynamically linked.

• The imd files are stored next to their dynamic library counterpart.

• The system path refers to the directory where these files are stored.