**1. Introduction**

Nowadays, lots of software have been developed based on components because of reusability and composability which can make development and maintenance easier. The component-based approach has some advantages that the cost and time required for maintenance and development can be reduced through the combination of components and the property of encapsulation. In particular, the robot software platforms such as OPRoS [1–3], openRTM [4, 5], and OROCOS [6], which are examples of component-based systems, have been using components of dynamic libraries, such as .dll and .so, in order for components to be able to be developed and maintained with ease. Despite these advantages, there are some hurdles in reusing of the components. The biggest hurdle is the binary compatibility issue of C++ based components, which is whether or not the components in the binary code compiled by a type of compiler are executing together on the same operating system with other components compiled by its old version compiler or other types of compilers. In practice, the number of components implemented with programming languages such as Java and Python has been increasing because those languages do not cause the binary compatibility problems. However, C++ is an important programming language needed for the control of automation machines/ devices such as robots and SW-based PLCs because it provides fast performance [7, 8]. In addition, there have been lots of C++ based components or modules

developed and stably used till now for industrial/office/home automation. Because the components were compiled by different types and/or versions of compilers, it is necessary to reuse them effectively. Therefore, the binary compatibility of C++ components (or objects) should be resolved. Note that examples of the components (or objects) are classes, variables, and methods, where a class can include variables, methods, and zero or more classes.

There are following two types of methods in dynamical sharing of C++ classes: the C-based dynamic library method and the sharing method supported by a compiler. Because the C-based dynamic library method cannot directly share classes, the executable files such as .exe, .dll, and .so refer to the abstract class of the same header files and deliver the address of the instance of the class. The sharing method by compiler can directly share classes. But the method cannot share instances of classes compiled by different types of compilers [9]. In other words, there is a serious problem that the sharing of classes is applicable only to the same compiler, which makes spreading of C++ based components difficult.

For instance, let us consider two types of components in the Windows environment, which are made using Visual C++ from Microsoft (MSVC) and GCC from GNU, respectively. A MSVC-based component and a GCC-based component are not mutually compatible in most cases even though they have been made in the same Windows environment. This situation occurs due to the binary compatibility problem. The binary compatibility problem generally causes the situations where the methods of the object cannot be suitably called or its operation is not properly executed. And then the system can enter into a down (or dead) state. To solve the problem, it is necessary to design an object structure compatible in all types of compilers [10].

There have been some researches to solve the binary compatibility problem of C++ objects, examples of which are COM [11], CCC [12], and ZL [13]. COM solves the binary compatibility problem of C++ objects but has some limitations that it should operate in a Windows environment and be supported only by the MSVC compiler [11]. CCC is a library that the classes are composed of only header files to maintain the binary compatibility and designed to use the C++ 11 features [14] to make binary compatible objects with ease. But CCC has a limitation that it can be used only by compilers that support the C++ 11 standard. In other words, CCC does not share objects compiled by compilers not supporting the C++ 11 standard. In the C++ compatible language ZL [13], the binary compatible classes are supported by customized preprocessors and macros. It does not however support multiple inheritances and provides the binary compatibility only for GCC because the compiler for ZL is made from modified version of GCC. In addition COM and CCC do not support the method overloading, but ZL partially supports it. CCC supports exception handling, COM does it in the restricted manner, but ZL does not support it.

This chapter proposes the binary compatibility object model for C++ (BiCOMC) for reusability of software components which provide binary compatibility for sharing objects between C++ executable files in the Windows or the Linux environment. In addition, the proposed model provides the method overloading and overriding, multiple inheritance, and exception handling. And BiCOMC makes each other share the objects generated by different types of compilers such as MSVC, GCC, and ICC. This chapter provides macros of C++ preprocessor for sharing the binary compatible objects easily and independently of the types and versions of compilers. This chapter illustrates how to use the proposed model via a simple example in the Windows and Linux environment. To validate the proposed method, BiCOMC is compared with COM and CCC in terms of the call time during execution and the binary compatibility among interface versions and the types of compilers. Moreover, it is shown that BiCOMC-based components made using both MSVC and GCC can call the methods of each other and the interface version problems are resolved.

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

In the next section, a binary compatibility object model for C++ (BiCOMC) is proposed, which has the structures of virtual function tables including multiple inheritance and the casting algorithm for conversion of interfaces. It is shown that method overloading and multiple inheritances are supported. In Section 3, the component based on BiCOMC is defined, and its implementation is shown using examples. Section 4 suggests two examples. One is a simple example to illustrate how to use the proposed method in Windows and Linux environment. The other is an example of a robot application to validate the proposed method, where the application consists of three components compiled by different types of compilers. In Section 5, the binary compatibility and the performance measure of the call time of methods are evaluated. Finally, the conclusions are given in Section 6.
