IT-SC book: Advanced CORBA® Programming with C++

module CCS {

typedef short TempType;

#pragma ID TempType "DCE:700dc518-0110-11ce-ac8f-0800090b5d3e:1" interface Thermometer {

#pragma prefix "climate.acme.com"

readonly attribute TempType temperature;

};

interface Thermostat : Thermometer {

void set_nominal_temp(in TempType t);

};

#pragma ID Thermostat "LOCAL:tmstat_rev_1.19b_checked" };

#pragma ID CCS::Thermometer "IDL:comp.com/CCS/Thermometer:1.0"

The repository identifiers for this specification are as follows:

IDL:acme.com/CCS:1.0

DCE:700dc518-0110-11ce-ac8f-0800090b5d3e:1

IDL:comp.com/CCS/Thermometer:1.0

IDL:climate.acme.com/temperature:1.0

LOCAL:tmstat_rev_1.19b_checked

IDL:acme.com/CCS/Thermostat/set_nominal_temp:1.0

The ID pragma must follow the type to which it assigns a repository identifier. It cannot precede it because the type name used in the pragma is resolved following the usual scope resolution rules (qualified type names are allowed).

This example also demonstrates that a prefix pragma extends only as far as its enclosing scope. (The prefix for set_nominal_temp is acme.com and not climate.acme.com.)

4.20 Standard Include Files

The CORBA specification requires every ORB to provide a file with the name orb.idl. If you intend to pass an IDL type description to a remote object, you must include orb.idl in your specification:

#include <orb.idl>

// Your specification here...

orb.idl contains the definition for CORBA::TypeCode as well as definitions for all types used by the Interface Repository. We discuss type codes in more detail in Chapter 16. Note that depending on your ORB, the orb.idl file may be in a subdirectory (such as corba), so you may have to modify the include path to specify the correct directory.

4.21 Recent IDL Extensions

In 1997, the OMG accepted a proposal to add new types to IDL. Following is a brief summary of these new types. Be aware that even though these extensions are officially

117

IT-SC book: Advanced CORBA® Programming with C++

part of CORBA 2.2 and later versions, they are unlikely to be available for some time. Availability not only depends on ORB vendors updating their code but also requires support from the underlying architecture and compilers (for example, to support 64-bit integer arithmetic). If you decide to rely on the new types, you need to make sure that they are supported by the platforms you intend to use.

4.21.1 Wide Characters and Strings

Two new keywords—wchar and wstring—are used for wide characters and wide strings, respectively. The specification does not mandate support for particular codesets, such as Unicode. Instead, it allows each client and server to use the codeset native to the local machine, and it specifies how characters and strings are to be converted for transmission between environments using different codesets.

Wide character and string literals follow the C++ syntax of prepending an L to the literal:

const	wchar	C = L'X';
const	wstring	GREETING = L"Hello";

In addition, wide characters and wide strings provide Unicode escape sequences of the form \uhhhh. For example, the letter ? can be represented by the escape sequence \u03A9. Leading zeros are optional, and the hexadecimal digits a to f can be in uppercase or lowercase:

const	wchar	OMEGA = L'\u03a9';
const	wstring	OMEGA_STR = L"Omega: \u3A9";

Wide strings must not contain the character with value zero (\u0000).

4.21.2 64-bit Integers

The type extensions add type long long and type unsigned long long for 64bit integer types. Language mappings for these types are not yet complete, so you should use them only if your architecture natively supports 64-bit integers.

4.21.3 Extended Floating-Point Type

The IDL type long double is used to specify an extended floating-point type. The specification requires IEEE 754-1985 format [7] (at least 64-bit mantissa and at least 15bit exponent). Language mappings for long double are not yet complete, so you should use this type only if your architecture provides native support for extended floating-point values.

4.21.4 Fixed-Point Decimal Types

118

IT-SC book: Advanced CORBA® Programming with C++

The type extensions add the fixed keyword for specifying fixed-point decimal types. Fixed-point types permit accurate representation of decimal fractions. Floating-point types permit exact representation only when the value happens to be a fractional power of 2. This makes fixed-point types particularly useful to represent business quantities, such as monetary amounts or interest rates. Here are examples of fixed-point types:

typedef fixed<9,2>	AssetValue;	// up	to 9,999,999.99,
typedef fixed<9,4>	InterestRate;	//	accurate to 0.01
		// up	to 99,999.9999,
typedef fixed<31,0> BigInt;		//	accurate to 0.0001
		// up	to 10^31 - 1

The first number in a fixed type definition specifies the total number of digits, and the second number specifies the scale—that is, the number of digits following the decimal point. A fixed type is limited to at most 31 digits, and the scale must be a positive number (zero is legal as a scale value).

The following IDL shows some examples of legal and illegal uses of type fixed:

const fixed val1 = 3.14D; const fixed val2 = -3000D; const fixed rate = 0.03D; typedef fixed<9,2> AssetValue; typedef fixed<3,2> Rate;

struct FixedStruct {		// Bad style, but OK
fixed<8,3>	mem1;
AssetValue	mem2;
};
interface foo {
void record(in AssetValue val); // OK
void op(in fixed<10,4> val);			// Illegal anonymous type!
};

Note that fixed-point literals must end in the character d or D. The integer or fraction part (but not both) is optional, as is the decimal point. For constant definitions, we use the keyword fixed without specifying the digits and scale of the constant. This is because digits and scale are implicit in the fixed-point literal. For example, 03.14D implicitly has the type fixed<3,2>, and -03000.00D implicitly has the type fixed<4,0> (leading and trailing zeros are ignored).

You can use the in-fix arithmetic operators (+, -, *, /) and unary minus (-) for fixed-point constant definitions. You cannot mix fixed-point, integer, or floating-point operands in a constant expression. Be careful about overflow; if an intermediate value or the final value has more than 31 digits, truncation without rounding occurs.

Even though it is not strictly required, we strongly recommend that you use a typedef for all fixed-point types. This technique avoids problems with anonymous types in some language mappings.

119

IT-SC book: Advanced CORBA® Programming with C++

Languages such as Ada and COBOL have direct support for fixed-point types, and that gives natural mappings. For languages such as C++ and Java, fixed-point types are supported by abstract data types.

The specification for fixed was changed significantly in CORBA 2.3 because the CORBA 2.2 specification for fixed-point types suffered from a number of problems. In particular, the syntax for fixed-point constants as well as the C++ mapping for fixedpoint types are different in CORBA 2.3. For these reasons, we recommend that you use fixed-point types only with an ORB that supports CORBA 2.3 or later.

4.21.5 Escaped Identifiers

The Objects-By-Value Specification adopted for CORBA 2.3 adds the notion of escaped identifiers to IDL. The need for these identifiers arose because ongoing extensions to CORBA occasionally require the addition of new keywords to IDL. This creates a problem: whenever a new keyword is added to IDL, it may potentially clash with an existing specification that uses that keyword. Consider the following IDL:

typedef string valuetype; // Syntax error in CORBA 2.3 and later interface Value {

valuetype	get_value();
void	set_value(in valuetype val);
};

This IDL is perfectly valid for an ORB that conforms to CORBA 2.2 or earlier. However, for an ORB compliant with CORBA 2.3, the definition of valuetype causes a syntax error because valuetype is one of the keywords added to the CORBA 2.3 specification. To make it possible to add new keywords to OMG IDL without completely breaking existing specifications, identifiers are allowed to have a leading underscore:

typedef string _valuetype; // OK in CORBA 2.3 and later interface Value {

_valuetype	get_value();
void	set_value(in _valuetype val);
};

Note the leading underscore on _valuetype, which maps the identifier away from the valuetype keyword. This mechanism allows us to migrate the earlier IDL definition that is no longer valid in CORBA 2.3 simply by adding an underscore to all occurrences of the now illegal valuetype identifier. The IDL compiler treats identifiers with a leading underscore exactly as if they did not have an underscore. In other words, the language mapping for the _valuetype identifier is exactly the same as if it had been spelled valuetype, and the repository ID is still IDL:valuetype:1.0. In that way, existing source code does not have to be changed if its IDL happens to contain an identifier that later becomes a keyword.

120