#contents

About _ptr_type and _var_type

When creating a template class, the object type, _ptr type, and _var type may each be required.

 interface Hello {
    void hello_world();
 };

If an interface like this is defined, Hello, Hello_ptr, and Hello_var will be used on the client side, but the _ptr and _var types are not simply pointers to Hello, so a declaration of a template class that uses all of these must be written as follows.

 template <class Hello, class Hello_ptr, class Hello_var)
 class HelloHelper
 {
   :
 } 

However, in practice, in omniORB and similar implementations, the _ptr type and _var type are each typedefed inside the Hello class as _ptr_type and _var_type. A part of the stub code generated by omniORB is shown below.

 typedef _objref_hello* hello_ptr; // _ptr は objref_hello* への typedef
 typedef _CORBA_ObjRef_Var<_objref_hello, hello_Helper> hello_var; // _var型
 class hello {
 public:
   // Declarations for this interface type.
   typedef hello_ptr _ptr_type; // hello_ptr は typename hello::_ptr_type
   typedef hello_var _var_type; // hello_var は typename hello::_var_type

It is defined in this way. Therefore, the above template can be written as follows.

 template<class ObjectType,
          class ObjectTypePtr = typename ObjectType::_ptr_type,
          class ObjectTypeVar = typename ObjectType::_var_type>
 class HogeHelper
 {
    :
 } 

However, as far as the CORBA specification is concerned, _ptr_type and _var_type do not seem to be defined as standards, so this method is not portable. It seems certain to work at least only with omniORB4, but it is not clear how these are defined in other implementations. (If the definitions differ, it can be used by giving the _ptr type and _var type as the second and third template arguments, respectively…)

How They Are Defined in Other ORBs

omniORB4

As described above, _ptr_type and _var_type can be used.

TAO

The same method can also be used with TAO. The following is an excerpt from a TAO stub.

 class  Hello
    : public virtual CORBA::Object
  {
  public:
    friend class TAO::Narrow_Utils<Hello>;
    typedef Hello_ptr _ptr_type;
    typedef Hello_var _var_type;

MICO

MICO also typedefs _ptr_type and _var_type in the same way, so the same method can be used. However, it seems that HAVE_TYPEDEF_OVERLOAD needs to be defined, but by default _ptr_type and _var_type seem to be accessible, so there appears to be no problem.

 class Hello : 
   virtual public CORBA::Object
 {
   public:
     virtual ~Hello();
     #ifdef HAVE_TYPEDEF_OVERLOAD
     typedef Hello_ptr _ptr_type;
     typedef Hello_var _var_type;
     #endif

ORBacus

Since I do not have a development environment at hand, I searched with google CodeSearch and found code like this, so the situation is thought to be the same.

 class Codec : virtual public CORBA::Object
 {
     Codec(const Codec&);
 public:
     Codec() { }
     typedef Codec_ptr _ptr_type;
     typedef Codec_var _var_type;

ORBit2

I found code like this with google CodeSearch. It appears to be a stub for CosNaming’s BindingIterator, and _ptr_type and _var_type are defined.

 class BindingIterator : public virtual CORBA::Object
 {
 public:
   typedef ::CosNaming::BindingIterator_ptr _ptr_type;
   typedef ::CosNaming::BindingIterator_var _var_type;