**2.1 Object model**

A BiCOMC is shown in **Figure 1** and has the interface Object as the root of the hierarchy of the class diagrams. Since interfaces are public and can be used by many objects, they do not have any member variables so that binary compatibility is maintained. Note that the interface Object has one pointer variable as shown in **Figure 1** for sharing of a virtual function table. The point variable is the vftptr pointer for accessing of the table and exists at the topmost of the interface. The structure of the virtual function table is explained later.

Let us consider the case where an executable file A can create an object but a different executable file B can delete the object. In this case, the memory allocated by the file A cannot normally be deleted using the C++ delete operator in the file B because the delete operator of the file B cannot invoke the destructor of the class in

**Figure 1.** *Class diagram of Object and ErrorDetail interface for BiCOMC.*

#### *Computer Methods and Programs in Biomedical Signal and Image Processing*

the file A. To solve this problem, the interface Object has a destroy() method so that objects can be deleted by the executable file which created the objects.

Because objects that are shared externally are exposed in the form of an interface, they cannot know the prototype of the object and then cannot be replicated through the C++ copy constructor. The interface Object has a clone() method that is allowed to clone the object.

When interface methods are implemented, the order of the methods in the virtual function table should be the same as the declaration order of the methods in the interface. So the order of the methods in the interface should not be changed once the interface is open in public. Adding a new method to the interface is allowed if its order is not changed. In other words the insertion of a new method is allowed only as the last method of the interface.

All methods can cause exceptions which are related to the interface ErrorDetail in **Figure 1**. Therefore, only objects implemented in the interface ErrorDetail should be thrown at the occurrence of the exceptions. The interface ErrorDetail has a value() method, a category() method, and a message() method that return an error value, an error category, and a description of the error, respectively.

An interface can inherit only one parent interface, but a class can inherit multiple interfaces. When a class has inherited multiple interfaces, the class has multiple vftptr pointers, which are the addresses of virtual function tables for individually inherited interfaces. The class, which is inherited multiple interfaces, refers to as many virtual function tables as the number of the inherited interfaces, which is shown in **Figure 3**.

## **2.2 Structure of a virtual function table**

The vftptr pointer of the interface Object points to a virtual function table. A virtual function table contains the address of the overridden method and the interface information for the interface. **Figure 2** shows the structure of the virtual

**Figure 2.** *Structure of a virtual function table.*

function table. The sizes of depth, version, and next offset are equal to the size of a void pointer (or void\*), respectively.

A virtual function table contains all the parent interfaces inherited by the interface. The first element, depth, of a virtual function table in **Figure 2** stores the number of inheritances from the interface Object to the last interface. If the interface directly inherited by the implementation class is the interface Object, the value of depth is 0. The second element, version, means the version number of BiCOMC for future extension of BiCOMC. The third element, next offset, is used for the objects that inherit multiple interfaces and represents the offset between the current vftptr and the next vftptr, which is explained later. The fourth element Object FT refers to the address of the function table of the interface Object where the actual addresses of overridden methods and the interface information are stored. The remaining elements i-th interface FT points to the function table of the i-th interface (i = 1… N).

The entry interface info in the function table means the interface information. The entry j-th mth. addr. (j = 1… M) is the address of the j-th method. Note that the addresses of the methods are stored in the same order as the order of declaration of the methods.

The interface info includes some elements such as hash, subhash, mth. count, interface name, and j-th mth. sig. (j = 1… M). The hash is a 64bit value, and it is calculated with the name of the interface and the names of inherited interfaces. The same hash means that the name of the interface and the names of the inherited interfaces are the same. The subhash is also a 64bit value, and it is calculated with M method signatures which contain the name of the method, a return type, and parameters' types. The same subhash means that the method definitions of two interfaces are the same. The sizes of the hash and the subhash of the interface may not be the same as the size of void\*. Their sizes are calculated in (1) in bytes. If the hash values of two objects are different, the objects are incompatible. The subhash values are used for the method overloading and backward compatibility. So the method signatures should be checked if the subhash values are not matched. Note that the interface name and the j-th mth. sig. (j = 1…M) are null-terminated character strings encoded by UTF-8 and j-th mth. sig. consists of the method name, the return type, and types of parameters:

$$\text{size} = \begin{bmatrix} 16/\text{sizeof}(\text{void}^\*) \end{bmatrix} \times \text{sizeof}(\text{void}^\*) \tag{1}$$

As mentioned above, the method signature can distinguish other methods with the same name because the method's signature is based on the method name as well as the types of parameters and the return type. So it can be said that BiCOMC supports the method overloading.
