BEA Logo BEA Tuxedo Release 7.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   Tuxedo Doc Home   |   Programming   |   Topic List   |   Previous   |   Next   |   Contents

   Programming a BEA Tuxedo Application Using TxRPC

Portability of Code

The output from the IDL compiler is generated in a way to allow it to be compiled in a large number of environments (see the next chapter for a discussion of compilation). However, there are some constructs that don't work in various environments. Here are a few known problems.

When compiling with Classic (non-ANSI) C, "pointers to arrays" are not allowed. For example:

typedef long array[10][10];
func()
{
array t1;
array *t2;
t2 = &t1; /* & ignored, invalid assignment */
func2(&t1); /* & ignored */
}

This will make it difficult to pass "pointers to arrays" to operations as parameters in a portable fashion.

When using an array of strings where the string attribute is applied to a multi-byte structure, the results will not be as desired if the compiler pads the structure. This is not the normal case (most compilers do not pad a structure that contains only character fields), but at least one occurrence is known to exist.

Constant values are, by default, implemented by generating a #define for each constant. This means that names used for constants should not be used for any other names in the IDL file or any imported IDL files. A TxRPC-specific option on the tidl compiler, -use_const, may be used to get around this problem in an ANSI C environment. This option will cause const declarations instead of #define definitions to be generated. The constant values will be declared in the client and server stubs, and any other source file including the header file will simply get extern const declarations. Note that this has the restriction that the client and server stubs may not be compiled into the same executable file (or duplicate definition errors will occur).

There are several restrictions in the C++ environment:

When coding the client and server application software, you should use the data types generated by the IDL compiler, as defined in rpc/tidlbase.h (listed as Emitted Macro in the following table). For instance, if you use a long instead of idl_long_int, then the data type may be 32 bits on some platforms and 64 bits on others; idl_long_int will be 32 bits on all platforms. Here is a table that lists the generated data types.

IDL Type

Size

Emitted Macro

C Type

boolean

8 bits

idl_boolean

unsigned char

char

8 bits

idl_char

unsigned char

byte

8 bits

idl_byte

unsigned char

small

8 bits

idl_small_int

char

short

16 bits

idl_short_int

short

long

32 bits

idl_long_int

Machines with 32-bit long: long Machines with 64-bit long: int

hyper

64 bits

idl_hyper_int

Machines with 32-bit long:
Big Endian

struct
{
long high;
unsigned long low;
}

Little Endian

struct
{
unsigned long low;
long high;
}

Machines with 64-bit long:

long

unsigned small

8 bits

idl_usmall_int

unsigned char

unsigned short

16 bits

idl_ushort_int

short

unsigned long

32 bits

idl_ulong_int

Machines with 32-bit long: long Machines with 64-bit long: int

unsigned hyper

64 bits

idl_uhyper_int

Machines with 32-bit long:
Big Endian

struct
{
unsigned long high;
unsigned long low;
}

Little Endian

struct
{
unsigned long low;
unsigned long high;
}

Machines with 64-bit long:

unsigned long

float

32 bits

idl_short_float

float

double

64 bits

idl_long_float

double

void *

pointer

idl_void_p_t

void *

handle_t

pointer

handle_t

handle_t

As in C, there are several classes of identifiers in the IDL. Names within each class (that is, scope or name space) must be unique:

Note that an anonymous structure or union (without a tag and not defined as part of a typedef) cannot be used for an operation return or a parameter.