[omniORB] user defined type

[Sveta Shasharina]

Hi Duncan!

I do not understand why the c++ back-end does not figure out
the signature: it has to know the full signature in order to generate
correct C++ stubs, right?

Sveta



On Monday 13 August, "Sveta Shasharina" wrote:

> I am able to ask to ask the Parameter x in some operations about it's kind
> by using:
> 	name = x.paramType().kind();
>
> Then I will obtain numbers (with 21 standing for user-defined type)
> as a result.  I know how to convert these numbers to predefined
> types.  But how do I ask as operation for its correct signature with
> all types defined (icluding user-defined)?

Well, kind() returns a typecode kind. 21 is tk_alias, so you'll get
that if the IDL used typedef. You will encounter the other constructed
kinds as well, like tk_struct.

If a type is of a constructed kind (tk_objref, tk_struct, tk_union,
tk_enum, tk_array, tk_alias, tk_except, tk_value, tk_value_box,
tk_native, tk_abstract_interface) the type object will actually be of
class idltype.Declared. Calling decl() on it will get you the
corresponding idlast.Decl object. e.g.:

  if (x.paramType().kind() == idltype.tk_alias):
      alias_decl = x.paramType().decl()

      # typedef_decl has class idlast.Declarator, containing
      # information about the typedef declarator

      scoped_name = alias_decl.scopedName()
      # list representing the scoped name of the type


To get the signature of an operation, you have to iterate over the
parameters, and figure out the correct name for each one. Do you want
the C++ signature?  It would be nice if the C++ back-end could be
asked things like that, but at the moment it isn't that well factored.
The code to figure out operation signatures and things like that is
mixed in with the code which outputs the rest of the stubs.

If someone wants to refactor the C++ back-end to be useful in this
way, we'd be very happy to incorporate it...

Cheers,

Duncan.

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