The C++ object model uses a hidden pointer. This pointer is implemented at a memory location, which is situated just above the data structure that in a ‘C’ view represents the public part of the instance. The size of this pointer is added to the size of the instance. Thus, the size of the instance in a C implementation of COM or RCOM is increased by the size of a pointer when the component class is implemented in C++. This means that in memory the BKEGameControl instance is situated as:
other hidden items;
(This ‘C’ view uses the fact that in the examples above the IBKEGameControl interface is the main entry point of the BKEGameControl instance.)
Hard encapsulated modules are components. Apart from a small part of the supporting infrastructure, component based systems consist completely of components. Part of these components consists of fixed components and the other components are volatile. The fixed components are created at system initialization time. The volatile components are created and deleted during or between the run of tasks. The components are connected according to a preplanned wiring scheme. Connections with volatile components are always dynamic, but connections with fixed components may be dynamic as well. A component-based system may operate in one of a series of system modes. Each system mode corresponds to a task-scheduling plan and to a wiring scheme. Most connections are established before a new system mode is entered. Old connections that no longer will be used are released. In a given system mode a component may request the establishment or the release of a connection. If the infrastructure is made responsible for establishing and releasing connections, then it becomes possible to implement an effective garbage collector for released dynamically created components.