[omniORB] Help passing objects

Duncan Grisby dgrisby@uk.research.att.com
Mon, 28 Jun 1999 17:40:22 +0100


On Monday 28 June, Dietmar May wrote:

[...]

>   interface MyInterface;
>   interface MyFactory
>   {
>     MyInterface make_it ();
>   };
> 
>   MyInterface_ptr _sk_MyFactory::make_it ()
>   {
>     MyInterface_ptr p_my = new MyInterfaceImpl;
>     p_boa->obj_is_ready(p_my);
>   #if 0 //what's the difference?
>     return MyInterface::_duplicate(p_my);
>   #else
>     return p_my->_this();   //not in a member function
>   #endif
>   }
> 
> _this() returns a duplicated object reference for the target object (or =
> more precisely, it returns an object reference upon which =
> CORBA::release() must be called). _duplicate() accepts an object =
> reference of the target object and returns an object reference upon =
> which CORBA::release() must be called. So what is the difference between =
> using _this() and _duplicate()?

The important thing is that a pointer to a C++ implementation object
is _not_ a CORBA object reference. So, in fact, you shouldn't even say
MyInterface_ptr p_my = new MyInterfaceImpl() since the return value of
MyInterfaceImpl() is not necessarily compatible with MyInterface_ptr.
As I say, with the current omniORB implementation, the types happen to
be compatible, but this is not required by the spec.

So, you shouldn't call _duplicate() on a pointer to an implementation
object since _duplicate() operates on object references, and pointers
to implementation objects aren't object references. You must call
_this() on the implementation object to return a CORBA object
reference.

The 2.0 spec was extremely under-specified in this respect; the 2.2
spec is much more explicit about it. Section 20.35.1 on page 20-99 of
the 2.2 spec says that compliant ORBs are permitted to support
implicit creation of object references from implementation pointers,
but are not required to do so. Such code is thus not portable.
omniORB's POA implementation will not support it, since to do so would
make all sorts of things more complicated.

HTH,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --