|| ||          

---

Stubs and servants in C++

As an example, we show the stubs and skeletons for the ImageRep IDL definition. Given the IDL interface definitions of RefCountBase, ImageData and ImageRep (where ImageRep inherits from both RefCountBase and ImageData) we use the idl compiler to generate the following C++ binding (note that the same structure holds for any set of IDL definitions):

IDL binding in C++

The classes CORBA::Object and PortableServer::ServantBase are part of the Corba definition and are implemented by the ORB. The other classes are generated by the IDL compiler. The generated files are located in $HXSRC/HxCorba/idl/stubs.

• Stubs HxCorba::ImageData and HxCorba::ImageRep are defined in HxCorbaImageRep.h
• Skeletons POA_HxCorba::ImageData and POA_HxCorba::ImageRep are defined in HxCorbaImageRep_skel.h
• Tie POA_HxCorba::ImageRep_tie is defined in HxCorbaImageRep_skel_tie.h

Basically, we employ two ways to implement servants : using ties and using inheritance. The tie approach is used when there is an existing class that matches an IDL definition, e.g. the C++ class HxImageRep matches the IDL HxCorba::ImageRep definition. The inheritance approach is used when there is no existing class to implement the IDL definition nor do we want to be able to address the class to be implemented later on without using Corba.

Servants using ties

In the tie approach, the servant object is a combination of a tie (generated by the IDL compiler) and an object that actually implements the functionality. All that the tie does is forward all member function calls to the tied object. In case the argument types and result type of the member functions of the skeleton match the member functions of the "real" object there is nothing more to do.

However, in the case of e.g. ImageRep, the types do not always match exactly. Consider the following functions from the IDL interface:

    long     dimensionSize(in long d);
    ImageRep unaryPixOp(in string upoName, in TagList tags);

The argument and return type of the tie function POA_HxCorba::ImageRep_tie::dimensionSize match the HxImageRep::dimensionSize function of the real object in that the compiler can find a suited conversion. However, both the argument and the return type of POA_HxCorba::ImageRep_tie::unaryPixOp do not match HxImageRep::unaryPixOp. So, we have implemented a specialization of HxImageRep called HxImageRepTiedSvt with a member function HxImageRepTiedSvt::unaryPixOp that converts the argument, calls HxImageRep::unaryPixOp, and converts the return value.

Other classes in $HXSRC/HxCorba/Main/ that employ the tie mechanism are:

HxBlob2dTiedSvt, HxBSplineCurveTiedSvt, HxHistogramTiedSvt, HxImageRepTiedSvt, HxImageSeqTiedSvt, HxMatrixTiedSvt, HxNJetTiedSvt, HxPolyline2dTiedSvt, HxSampledBSplineCurveTiedSvt, HxSFTiedSvt, HxTagListTiedSvt, VxSegmentationTiedSvt, VxSegmentTiedSvt, and VxStructureTiedSvt.

A list of these is maintained in HxTiedServants.h to ... (check this)

Servants using inheritance

In the inheritance apporach, we make the object that implements the functionality a specialization of the skeleton. That is, in the ImageRep example it would be derived from POA_HxCorba::ImageRep.

Classes in $HXSRC/HxCorba/Main/ that employ the inheritance mechanism are:

HxConfigureServant, HxConstructorServant, HxRegistryServant, HxRgbBufferServant, and HxTestServant.

Taglists

Taglists require special care, because (up till now) HxCorba::TagList is the only Corba object that the user can modify. And, only TagList arguments can be nil.

One difference is the constructor. HxTagList has an empty constructor. The way a TagList is constructed (Corba TagList, not HxTagList) is that the user creates an empty TagList and calls its operations to add tags. The other Corba objects are created from a C++ object obtained from a C++ operation.

Now we can not instantiate a TagList from an HxTagList. To do that we would have to define a constructor for HxTagListTiedSvt with an HxTagList as argument, with the problem that we would instantiate a servant for a copy of that HxTagList, not that HxTagList itself.

Another difference is the way we obtain the tied object from the servant. This is done with the template function HxGetTiedObject. This function has the tied servant as template and requires that the template has the next typedefs:

• HxT: the Horus type (for example HxImageRep)
• CorbaT: the Corba type (for example HxCorba::ImageRep)
• TieT: the TIE class type (for example POA_HxCorba::ImageRep_tie<HxImageRepTiedSvt>)

(we use ImageRep as example, but actually ImageRepTiedSvt doesn't have these typedef's because the conversion functions HxGetTiedObject and HxRegisterTiedServant can not be applied to ImageRep because the ImageRep servants are registered in a different POA :-)

The call to HxGetTiedObject is a little different for TagList because an argument of type TagList can be nil and HxGetTiedObject must return (in case of nil) an empty HxTagList, and this empty HxTagList has to be provided as an argument to HxGetTiedObject.

Why doesn't HxGetTiedObject create itself the empty HxTagList? Because the result to HxGetTiedObject is assigned to a reference of HxTagList, not copied to another HxTagList. And the empty HxTagList will be disposed when it goes out of scope: it doesn't survive the call of HxGetTiedObject.

Why doesn't HxGetTiedObject create the empty HxTagList with "new"? Because the caller of HxGetTiedObject can not do a "delete": this delete will mess up things in the case that HxGetTiedObject returns a tied HxTagList, not an empty one.

And why the result of HxGetTiedObject is assigned to a reference of HxTagList, not just to a HxTagList (using the assignment operator)? The call to HxGetTiedObject for all the other types of tied servants are not assigned to a reference, but HxTagList is different: An HxTagList can be modified via a Corba call and we want to modify the real HxTagList, not a copy.

---

Go to the next section or return to the index.

---