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

This problem not only exists for enumerations but also occurs if we want to extract any user-defined type without linking against the IDL-generated code for that type. We simply do not have the necessary extraction operator to get a value of user-defined type out of an Any, even though we can interrogate the Any's type code to learn about the type of the value.

In Chapter 17 we discuss how to use type DynAny to get around this limitation.

16.5 Type Code Comparisons

The show_TC function relies on being able to detect whether a particular type code was processed earlier. We detect an already-processed type code by using the STL find_if algorithm:

where = find_if(tlist.begin(), tlist.end(), EqualTypeCodes(tcp));

Here, we pass the EqualTypeCodes function object to find_if. The conversion operator to bool in EqualTypeCodes carries out type code comparison during the traversal of the container:

//

//Predicate object for find_if algorithm. Returns true

//if a type code in a container is equal to the type

//code passed to the constructor.

//

struct EqualTypeCodes { EqualTypeCodes(

CORBA::TypeCode_ptr tc ): _ptr(tc) {}

bool operator()(CORBA::TypeCode_ptr rhs) const { return _ptr->equal(rhs);

}

CORBA::TypeCode_ptr _ptr;

};

The constructor of EqualTypeCodes stores the current type code in the variable _ptr, and the conversion operator calls TypeCode::equal to compare the remembered type code against the current type during iteration.

16.5.1 Semantics of TypeCode::equal

What does it mean for two types to be equal, as determined by TypeCode::equal? Unfortunately, the answer depends on whether you are using a CORBA 2.3 ORB for the comparison and whether the type codes were created by a CORBA 2.3 or earlier ORB. The behavior of the TypeCode::equal operation is well defined in CORBA 2.3 but has implementation-dependent behavior in earlier versions (or, more bluntly, equal was underspecified before CORBA 2.3).

620

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

For CORBA 2.3, equal performs an exact comparison and returns true only if two type codes are identical in all respects. All operations that apply for the two type codes' TCKind values must return identical results for equal to return true. Member names, type names, repository IDs, and aliases are all considered significant and must be the same.

For CORBA 2.2 and earlier, equal has implementation-dependent behavior. It may or may not consider aliases significant, and it may or may not consider type names and member names significant. (The repository ID is considered significant in all implementations we are aware of.)

The difference in behavior arises because of the parameters marked as optional in Table 16.1 on page 696. For CORBA 2.2 and earlier, repository IDs and type and member names are optional. Because of this, the outcome of a comparison with equal depends on whether or not an ORB chooses to marshal repository IDs and on whether type and member names are present in a type code. To make matters worse, the behavior of equal was never clearly defined in CORBA 2.2, so the outcome of a comparison also depends on your particular ORB implementation. The remainder of this section uses the following IDL definition to illustrate this behavior:

struct foo { long l_mem; string s_mem;

};

typedef foo alias_of_foo;

struct bar {

long long_member; string string_member;

};

Note that foo and bar are structurally equal—that is, they contain the same number and type of members in the same order—so the differences are confined to their repository IDs, type names, and member names.

Using equal in a CORBA 2.3 ORB

Assuming that both type codes were created by a CORBA 2.3 ORB, comparisons of the three types with equal in a CORBA 2.3 ORB have the following outcomes.

foo and bar are not equal.

foo and alias_of_foo are not equal. bar and alias_of_foo are not equal.

In other words, in CORBA 2.3, given CORBA 2.3 type codes, equal implements a precise comparison and requires all parameters of the two type codes to be exactly the same.

621

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

If one or both type codes were created by a pre-CORBA 2.3 ORB, comparison of the three types with equal in a CORBA 2.3 ORB depends on how much information is present in the type codes.

If at least one of the type codes preserves the repository ID or a type or member name, equal is reliable and returns the same results as for CORBA 2.3 type codes (that is, it implements a precise comparison).

If neither type code preserves any of its optional parameters, equal uses structural comparison.

foo and bar are equal.

foo and alias_of_foo are not equal. bar and alias_of_foo are not equal.

Using equal in a CORBA 2.2 or Earlier ORB

With a CORBA 2.2 ORB, the outcome of comparisons depends on the origin of the type codes.

If both type codes were created by the same ORB, the comparison works as in CORBA 2.3 (at least in all ORB implementations we are aware of).

If the type codes were created by different ORBs, the outcome depends on the implementation of equal as well as the amount of information that is present in the type codes. This means that equal in CORBA 2.2 has implementation-dependent behavior for all three comparisons.

16.5.2 Semantics of TypeCode::equivalent

The CORBA 2.2 situation with respect to type comparison was highly unsatisfactory. Even though many applications never use type codes directly, the imprecise comparison semantics caused a number of portability and interoperability problems. To address this, CORBA 2.3 added a precise definition for equal, as explained in the preceding section. In addition, CORBA 2.3 introduced the Type-Code::equivalent operation.

The equivalent operation performs type code comparison while ignoring aliases. The operation first follows alias chains that may be present in either type code by ignoring all type codes with tk_alias; then it uses the repository IDs of the unaliased type codes to determine whether the two type codes are the same. The exact outcome depends on the origin of the type codes.

If both type codes were created by a CORBA 2.3 ORB, equivalent produces the following results.

foo and bar are not equivalent.

622

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

foo and alias_of_foo are equivalent. bar and alias_of_foo are not equivalent.

If one or both type codes were created by a pre-CORBA 2.3 ORB, the outcome depends on how much information is carried by the type codes.

If both type codes carry repository IDs, the outcomes are as follows.

foo and bar are not equivalent.

foo and alias_of_foo are equivalent. bar and alias_of_foo are not equivalent.

If one or both type codes omit the repository ID, all three pairs of types are considered equivalent.

Intuitively, the behavior of equivalent is that it performs a comparison that ignores aliases but otherwise treats types with different names as distinct even if they are structurally equivalent. However, if the type codes do not carry a repository ID, equivalent falls back to a structural comparison.

16.5.3 Why Make Names Optional in Type Codes?

Considering the difficulty it creates, you may wonder why CORBA 2.2 allowed repository IDs and type and member names to be the empty string. The motivation for optional parameters is to save bandwidth when type codes are marshaled over the wire. For example, again consider the union from the climate control system:

union KeyType switch(SearchCriterion) { case ASSET:

AssetType asset_num; case LOCATION:

LocType loc; case MODEL:

ModelType model_num; };

The type code for this union describes the union itself and also contains the type code for the enumerated discriminator. If a type code carries a repository ID, type name, and member names, the type code for this union contains the following strings, all of which are sent over the wire:

IDL:acme.com/CCS/Controller/SearchCriterion:1.0 // Repository ID

623

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

The strings for the various names consume a total of 147 bytes, not counting NUL terminators. In other words, the type code for a KeyType union is 147 bytes larger if all these names are present than if the names are empty. Considering that a value of type KeyType consists of an enumerated value for the discriminator and either a string or a number, this overhead is substantial. The type codes for unions, structures, exceptions, and enumerations suffer from this problem most often; the names account for the bulk of the size of a type code when it is marshaled. When you are sending values of type any over the wire, it can happen that the actual value in the any is only a few bytes long, whereas its associated type code consumes several hundred bytes. This problem becomes particularly noticeable when you are using complex types with the OMG Event Service (see Chapter 20), which uses type any to distribute events.

For CORBA 2.3, the repository ID is mandatory, and only type and member names can be empty. In that case, the type code for the union carries 86 bytes for its strings, still a substantial saving compared with 147 bytes.

16.5.4 Portability of Type Code Comparisons

The differences in the TypeCode interface and the different semantics of equal between CORBA 2.2 and 2.3 create a portability problem. How can you write code that reliably compares type codes with the desired semantics?

For CORBA 2.3, the answer is easy. You can use either equivalent or equal as appropriate for your application because both operations have well-defined semantics in CORBA 2.3. In addition, even with pre-CORBA 2.3 type codes, equal and equivalent perform comparisons that give the correct results in most cases. (False positives happen only if type codes do not carry a repository ID.)

For CORBA 2.2 ORBs and earlier, equivalent does not exist and equal has implementation-dependent behavior. If you do not care about stripping aliases, it is probably safe to use equal, because for all pre-CORBA 2.3 ORBs we are aware of, equal performs an exact comparison that does not ignore aliases. If you require comparisons that ignore aliases for a pre-CORBA 2.2 ORB, it is safest to write your own comparison function that first strips aliases before passing a type code to equal. (Keep in mind, though, that if an ORB omits both repository IDs and names in type codes, you can perform only a structural comparison because the information for more strict semantics is not available.)

16.5.5 Semantics of Extraction from Type any

624

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

The semantics of type code comparison become most visible when you are extracting a value from an Any because extraction fails if a value does not match the type as which it is extracted. For CORBA 2.3 and later revisions, ORBs use equivalent to determine whether extraction should succeed. For CORBA 2.2 and earlier revisions, successful extraction depends on the (underspecified) semantics of equal.

Here is an example to illustrate this point. (Assume the IDL definitions of foo and bar on page 716.)

foo f = ...; alias_of_foo aof = ...; bar b = ...;

The matching extraction succeeds in CORBA 2.3 and succeeds in all CORBA 2.2 ORBs we are aware of. The alias extraction succeeds in CORBA 2.3 and may or may not succeed in CORBA 2.2. The non-matching extraction fails in CORBA 2.3 but may or may not fail in CORBA 2.2.

Unfortunately, for your program to remain portable in CORBA 2.2 environments, your only defense is to write your own comparison operation that you can call before attempting an extraction. But keep in mind that even this approach is limited by the information that is actually present in the type codes you compare. (This becomes an issue if you receive any values from programs written using an older ORB.)

In Section 16.7 we discuss how you can explicitly test for a specific alias during extraction.

16.5.6 Structural Equivalence

Some applications require structural type equivalence. For example, it may be necessary to always treat the types foo and bar on page 716 as equivalent. Your only choice for implementing such structural equivalence is to write your own comparison function that ignores the repository ID and names in type codes and performs comparisons based purely on identical TCKind values at each nesting level.

16.5.7 The get_compact_typecode Operation

625