_var_type, _ptr_type_en

About _ptr_type, _var_type

When creating a template class, it is sometimes necessary to specify the object type, the _ptr type, and the _ var type.

 interface Hello {
    void hello_world();
 };

If you define an interface such as Hello, Hello_ptr, Hello_var on the client side, since the _ptr, _ var type is not just a Hello pointer, declaration of a template class that uses all of them,

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

You have to write like. However, in fact, in omniORB etc., _ptr type and _ var type are typedef in _ Hello class, _ptr_type, _ var_type, respectively, and this is used. A part of the code of the stub generated by omniORB,

 typedef _objref_hello* hello_ptr; // _ptr is a typedef to objref_hello *
 typedef _CORBA_ObjRef_Var<_objref_hello, hello_Helper> hello_var; // _var type
 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

This is defined. Therefore, the above template is multiplied as follows,

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

However, as far as CORBA's specification is concerned, it seems that _ptr_type and _var_type are not defined as standards, so this method is not a portable way. At least with omniORB 4 it seems to work reliably, but in other implementations, I do not know how it is defined. If the definitions are different, you can use it if you give _prr type or _ var type to the second and third arguments of template respectively. . .

How to define in other ORB

omniORB 4

As described above, _ptr_type and _var_type can be used.

TAO

In TAO, the same method can be used. Below is a snippet of TAO's 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

Similarly for MICO, since _ptr_type and _var_type are typedefed, the same method can be used.

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

However, although HAVE_TYPEDEF_OVERLOAD seems to need to be defined, it seems that there is no problem because it seems that you can access _ptr_type, _var_type by default.

ORBacus

Since there is no development environment at hand, I searched by google CodeSearch,

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

There was such a code, so the situation seems to be the same.

ORBit2

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

I found such a code. with google CodeSearch. It seems to be a stub of CosNaming's BindingIterator, but _ptr_type, _var_type is It is defined.

latest Releases

For Begginers

Windows msi(installer) package (only trying samples)

Development environment is required for RT-Component development. See download page for details.

Number of Projects

OpenHRP3

Dynamics simulator

OpenHRI

Human-Robot-Interaction RTCs

OpenRTP

Integrated Development Platform

OpenINVENT

Mobile Robot RTCs