![]() |
The CORBA 2.1 C++ client bindings define a variety of C++ types corresponding to a single IDL interface. For example, an IDL interface I is mapped to C++ types with the following four names:
- I
- I_ptr
- IRef
- I_var
The types named I and I_var are classes. The types I_ptr and IRefare unspecified by CORBA, but are required to name the same type; these types are the C++ form for an object reference.
Note: The use of the IRef types will be removed by the CORBA 2.1 specification.The class I is referred to as the interface class corresponding to IDL interface named II; the C++ mappings of the typedefs, operations, and constants defined within the IDL interface I appear publicly within the C++ interface class I. For example, an IDL operation that accepts an in parameter of interface type I is mapped to a C++ virtual member function of the class named I that has a parameter of type I_ptr. Similarly, an IDL operation in I that returns data of type I is mapped to a C++ member function in the class I that returns data of type I_ptr.
As with other user-defined IDL types, the I_var type is used to assist storage management. Specifically, an I_var type holds an I_ptr and can be used as if it were an I_ptr. When an I_var type is assigned a new value or when it goes out of scope, it releases the I_ptr it is holding at that time.
The CORBA 2.1 specification prohibits CORBA-compliant applications from:
- Explicitly creating an instance of an interface class, as in:
I my_instance; // NOT ALLOWED! I_ptr my_instance = new I; // NOT ALLOWED!- Declaring a pointer (I*) or a reference (I ) to an interface class.
Instead, the I_ptr, IRef, and I_var types must be used to hold object references, and object references can only be created (by client applications) by invoking methods that return object references. The interface class I is used by client applications only as a name scope.
IDL operations defined in (or inherited by) interface I are invoked in C++ using the arrow (->) operator on either an I_ptr, IRef, or I_var type.
Nil object references of type I_ptr can be obtained using a static member function of I called _nil(). Operations cannot be invoked on nil object references. The CORBA::is_nil function is the only CORBA-conformant way to determine whether a given object reference is nil. CORBA::release can be invoked on a nil object reference, but is not needed. The _duplicate and _narrow functions defined by the C++ bindings can be given a nil object reference.
In the IBM C++ bindings, the CORBA-prescribed types are implemented as follows:
- The interface class for I is derived using virtual inheritance from the interface classes for I's IDL parents. When I has no IDL parents, its interface class is derived using virtual inheritance from CORBA::Object. Types, constants, and operations declared within the I interface are mapped to types, constants, and member functions declared within the corresponding interface class.
- The object reference types I_ptr andIRef are typedef'd to I* (for example, an I_ptr points to an object of type I). However, CORBA 2.1 specifies that treating an I_ptr as a C++ pointer (e.g., using conversion to void*, arithmetic and relational operators, test for equality) is not conformant, although this is not enforced by the bindings.
- An instance of I addressed is called a proxy, and is created by a proxy factory object of class ProxyFactory. For each interface I, the bindings define a ProxyFactory class, and provide a global instance of this class with the name _ProxyFactory.
- Nil object references are represented as NULL pointers (but CORBA 2.1 conformant applications should not assume so, and should instead use the _nil() and is_nil() functions to manipulate nil object references).
- The I_var class introduces an instance variable of type I_ptr. The purpose of an I_var object is to handle release operations on the I_ptr that it holds.
- An auxiliary class I_SeqElem is used to return sequence elements, and is similar to the I_var class. It is returned from array access operations on an IDL type sequence. An I_SeqElem is different from an I_var in that it must honor the release setting of the sequence from which it is selected (that is, it only owns the object that its I_ptr references if it was taken from a sequence that owns its buffer storage).
For more details on C++ bindings for CORBA interfaces, see the following topics: