The C representation of the VOOPS save file is the class table which holds information about each class known to VOOPS. Besides the class ID, the parent class ID, the class name and structure size, all methods are stored as C function pointers in the class table. But since the number of methods is not known in advance, this table grows with each new unique method. This has the implication that when a new method is added in a *_c.tpl file, the master header file of the module has to be rebuilt, and therefore all other files depending on it.
A special feature is the implementation of class masks, which are used to check whether a specific method can be applied to a given object, or, in object-oriented terminology, if a specific message can be sent to the object in question. This is done through comparing the object's class mask (accessed through the class ID stored in the object) to the class mask of the class the method is defined on with a logical AND operation. If there is a match, the method can be applied, otherwise the object is rejected. Since this feature should be only necessary on debugging, the corresponding code is included in an #if CHECK - #endif pair.
The class table declaration is generated at the end of the master header file, whereas the class is actually defined at the beginning of the master source file. Many class-independent access macros are defined to aid retrieving information from the class table, to obtain and set the object ID of object instances, and to test, set, and clear certain object flags.
Object flags are stored in the upper bits of the 32-bit object ID of
an object, which are not used to encode the object ID. Due to the 32-bit
integer used to store the class mask in the class table, the maximum number of
supported classes is currently 32. This means, that at most 
bits
are actually used in the object ID entry to encode the object ID. The
remaining 27 bits can be used for binary flags which are often useful for
tagging objects during sweep- or scan-like algorithms.