Bionic Buffalo Tech Note #23: The France IDL Compiler: C Language Mapping
structure whose form varies by the
kind
of definition. The structures are intended to be opaque to
applications, understood only by the
CORBA_TypeCode_*()
functions found in the
yemen
library.
The various structures (corresponding to different
kind
s of
TypeCode
s or definitions) all have the
partial definition
typedef struct tbt_typecode_basic_T
{
civ_magic_T
magic ;
uint_least32_t
flags ;
uint_least32_t
use_count ;
unsigned long
kind ;
... /* other members, depending on kind */
}
tbt_typecode_basic_T ;
The
magic
member is set to
TBT_TYPECODE_MAGIC
. One use of the
flags
bits is to specify
whether the
TypeCode
structure is statically allocated (by the compiler) or dynamically allocated (by
the
ORB
). There are no automatically allocated
TypeCode
s.
For IDL definition
xyz
, the generated
TypeCode
constant is named
TC_xyz
, and the referenced
data structure is named
vut_tc_xyz
.
Since
CORBA_free()
is oblivious to secondary storage, and since
TypeCode
s are architecturally a
sort of object, storage for
TypeCode
s must be freed using
CORBA_Object_release()
. It is
expected that
CORBA_Object_duplicate()
will effectively make a copy of a
TypeCode
. In
practice, only the
void *
pointer is duplicated, with a use count maintained for the number of
references.
Object References
The specification requires that object references be mapped to
void *
pointers. The compiler makes
no assumptions beyond this.
Interface and Operation Information
For each operation defined in IDL, the compiler creates a static data structure of type
tbt_operation_info_T
. This structure contains the information from the IDL regarding the
operation and its parameters, and is used by the stubs and skeletons for such purposes as marshalling
and unmarshalling of arguments. For operation
oper3
of interface
intf2
(for example), the structure
is named
vut_oper_intf2_oper3
.
For each interface defined in IDL, the compiler creates a static data structure of type
Page 3 of 6