Previous Contents Next

Chapter 3   C++ language mapping

Now that you are familiar with the basics, it is important to familiarise yourself with the standard IDL to C++ language mapping. The mapping is described in detail in [OMG99]. If you have not done so, you should obtain a copy of the document and use that as the programming guide to omniORB.

The specification is not an easy read. The alternative is to use one of the books on CORBA programming that has begun to appear. For instance, Henning and Vinoski's `Advanced CORBA Programming with C++' [HV99] includes many example code bits to illustrate how to use the CORBA 2.3 C++ mapping.

3.1   Incompatibilities with pre-2.8.0 releases

Before 2.8.0, omniORB implemented the CORBA 2.0 C++ mapping. From 2.8.0 onwards, the mapping has been updated to CORBA 2.3. Unfortunately, to comply with the CORBA 2.3 specification, it has been necessary to change the semantics of a few APIs in a way that is incompatible with older omniORB releases. The incompatible changes are limited to:

  1. The mapping for some out and inout argument types is different.

  2. The extraction of string, object reference and typecode from an Any has different ownership rules.

  3. the DII interface now defaults to reporting a system exception by raising a C++ exception, instead of returning the exception as an environment value.
The changes are minor and require minimal changes to the application source code. The C++ compiler will complain about the first change. However, it is not possible to detect the old usage for changes 2 and 3 at compile time. In particular, unmodified code that uses the affected Any extraction operators will most certainly cause runtime errors to occur.

To smooth the transition from the old usage to the new, an omniORB configuration variable omniORB::omniORB_27_CompatibleAnyExtraction can be set to revert the any extraction operators to the old semantics. More information can be found in chapter 9.

3.2   BOA compatibility

If you use the -WbBOA option to omniidl, it will generate skeleton code with the same interface as the old omniORB 2 BOA mapping, as well as code to be used with the POA. Note that since the major problem with the BOA specification was that server code was not portable between ORBs, it is unlikely that omniORB 3's BOA compatibility will help you much if you are moving from a different BOA-based ORB.

The BOA compatibility permits the majority of BOA code to compile without difficulty. However, there are a number of constructs which relied on omniORB 2 implementation details which no longer work.

Previous Contents Next