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:

The mapping for some out and inout argument types is different.
The extraction of string, object reference and typecode from an Any has different ownership rules.
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.

omniORB 2 did not use distinct types for object references and servants, and often accepted a pointer to a servant when the CORBA specification says it should only accept an object reference. Such code will not compile under omniORB 3.
The reverse is true for BOA::obj_is_ready(). It now only works when passed a pointer to a servant object, not an object reference. The more commonly used mechanism of calling _obj_is_ready(boa) on the servant object still works as expected.
It used to be the case that the skeleton class for interface I (_sk_I) was derived from class I. This meant that the names of any types declared in the interface were available in the scope of the skeleton class. This is no longer true. If you have an interface:
```
interface I {
  struct S {
    long a,b;
  };
  S op();
};
```
then where before the implementation code might have been:
```
class I_impl : public virtual _sk_I {
  S op();  // _sk_I is derived from I
};
I::S I_impl::op() {
  S ret;
  // ...
}
```
it is now necessary to fully qualify all uses of S:
```
class I_impl : public virtual _sk_I {
  I::S op(); // _sk_I is not derived from I
};
I::S I_impl::op() {
  I::S ret;
  // ...
}
```
The proprietary omniORB 2 LifeCycle extensions are no longer supported. All of the facilities it offered can be implemented with the POA interfaces, and the omniORB::LOCATION_FORWARD exception (see section 6.13). Code which used the old interfaces will have to be rewritten.