**5.2 Evaluation of backward compatibility of different interface versions**

In developing the program, it is necessary to add a new method to the existing interface. That is, the interface version is changed in this case, which is shown in **Figure 23**.

**Figure 23** shows two interfaces of *IfaceA* and *IfaceB*, where *IfaceB* inherits *IfaceA*. In the version *v1*, *IfaceA* has a method, *mth\_1()*. But the interface *IfaceA* should be upgraded to the new version *v2* because a new method of *mth\_3()* is added. Let us consider the following: the v1-related interfaces and the v2-related interfaces are used in the caller and the callee programs, respectively.

**Figure 22.** *Interface for binary compatibility test.*

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


#### **Table 2.**

*Tests of the binary compatibility in CCC.*


#### **Table 3.**

*Tests of the binary compatibility in C++.*

This test also uses simple methods that return values of 1, 2, and 3, respectively, which are similar to methods used in Section 5.1. The experiments are done using MSVC 14, GCC 5.2, and ICC 16 in Windows 10.

**Table 4** shows that BiCOMC can enable the binary compatibility between interfaces of versions *v1* and *v2*, but CCC, COM, and C++ are not compatible between codes with different interface versions. Therefore, BiCOMC supports the backward compatibility of interface versions. MSVC, GCC, and ICC generate a virtual function table in contiguous memory space regardless of inheritance. In this structure of the table, if a new method is added in the parent interface, the offset of child's methods will be changed. For this reason, C++ does not provide the backward compatibility. COM and CCC also have the same reason. BiCOMC has the structure


**Figure 23.** *Interface for backward compatibility test per version.*

*How to Keep the Binary Compatibility of C++ Based Objects DOI: http://dx.doi.org/10.5772/intechopen.77383*


**Table 4.**

*Tests of the backward compatibility.*

of **Figure 2** so that the parent's methods and the child's methods can be stored at independent memory space of each other. Thus BiCOMC supports the backward compatibility of interface versions.

### **5.3 Call time evaluation**

Call times as performance measures are measured in Windows 10 using MSVC 14, GCC 5.2, and ICC 16. The methods of objects are called 10 million times, and the call times are obtained as the average values of all call times. These are shown in **Figures 24**–**26**, in which MSVC, GCC, and ICC compilers are used for evaluation, respectively. In these figures, two notations such as *XXX* and *XXX-R* are used, where *XXX* is one of BiCOMC, CCC, CPP (or C++), and COM and *-R* means that the method used in the test has a return value.

**Tables 1**–**4** show that BiCOMC provides the best binary compatibility among different types of compilers. **Figures 24**–**26** show that C++ has the best call time, but the call time of BiCOMC is similar to those of C++ and COM. CPP is generally faster than others because the method calling accesses an optimized virtual function table which accesses directly addresses of methods. COM is also similar to CPP. Note that GCC does not support COM. CCC is slower as std::function, one of the C++ 11 features [14], is basically used [12]. BiCOMC is slower slightly than CPP and COM because it accesses addresses of methods in the *function table* pointed by the *virtual function table*. But the test results show no or little significant difference among BiCOMC and CPP/COM.

**Figure 24.** *Call time in MSVC.*

**Figure 26.** *Call time in ICC.*
