### The idl-generated Class Hierarchy

For C++ applications, the interface definition specifies a public interface class. This means that IDL data types specify public data members of the interface class, and IDL operations specify member functions. The IDL compiler generates interface class within C++ class hierarchies for both the client and server. The RPC network mechanisms are encapsulated in a class above the interface class. Clients use (and servers implement) the objects of classes below the interface class.

The rpc_object_reference Base Class
Because C++ makes it easy to hide information, the IDL compiler generates an rpc_object_reference base class for identifying, distributing, and tracking objects. All interface classes inherit the rpc_object_reference class, which encapsulates the following information:

· Object binding information, including server binding information and an object UUID representing the object on the particular server

· Transport protocol information for the server

· A name identifying an optional location in the namespace for the object's binding information

· A location flag indicating whether the object is on the local system or a remote system

· A reference count to keep track of how many clients currently access the object

The Interface Class
For each interface, the IDL compiler generates and places in the header file the interface class derived from the rpc_object_reference class. The class name generated is the interface name specified in the interface definition. For example, the compiler generates the following class:
class interface_name : public virtual rpc_object_reference

This is an abstract class that contains public functions for all the operations specified in the IDL interface. The member functions that are not static object creator functions are defined as pure virtual functions. In C++, an abstract class contains at least one pure virtual function, which means that the implementation is postponed until a later, derived class. Therefore, object instances cannot be created for abstract classes, and thus the interface class in not implemented but is only a declaration. Other classes must be derived from the interface class so that objects can be created for clients and servers.

No constructor operations are allowed in the interface definition, and the IDL compiler does not generate one because no objects are created for the interface class. No destructor operations are allowed in the interface definition, but the compiler generates one automatically for the interface class.

The Client's Proxy Class
The IDL compiler places in the header file a proxy class derived from the interface class. An instance of a proxy class is also known as an object reference, which clients use to access a remote object. This class provides proxy (or surrogate) objects on the client whose member functions (or methods) transparently perform the RPCs that invoke the actual remote object's member functions on the server. The proxy class name is generated from the interface name and the word Proxy, as follows:
class interface_name Proxy : public interface_name

Implementations of the proxy class's member functions are automatically generated in the client stub and represent the client's implementation of the interface's operations.

The Server's Manager Class
A manager class is required for servers to implement the interface. The class is generated by the IDL compiler and derived from the interface class as follows:
class interface_name_Mgr : public interface_name {
public:
.
.
.
}

The class is placed in a header file whose name is based on the IDL file and an _mgr suffix. When generated, the manager class contains empty function implementations and other implementation details of this class are called manager code.

###