1. OMG Issue

CORBA23 — TypeCode comparison proposal (01)

  • Key: CORBA23-201
  • Legacy Issue Number: 1622
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Points 1 through 9 need to be considered as one unit. Point 10 can be
    voted on independently, but does provide a useful capability for
    controlling the size and content of TypeCodes.


    1. Make RepositoryIds mandatory for all TypeCodes that have them. [This
    was done by the previous core RTF. I am just reiterating it here for

    2. All TypeCode constants generated by the IDL compiler, as well as all
    TypeCodes returned by the Interface Repository must include alias
    TypeCodes wherever a typedef declaration appears in the original IDL

    3. Each IDL programming language mapping must provide a mechanism for
    the programmer to ensure that values of the IDL any type contain the
    exact typecode desired by the programmer.

    4. The name() and member_name() fields of the TypeCode are for
    documentary purposes only, and are never considered significant when
    comparing TypeCodes.

    5. Define a new equivalent operation for TypeCodes:

    pseudo interface TypeCode

    { ... boolean equivalent(in TypeCode other); ... }


    with the following semantics:

    a) If the two TypeCodes are the same primitive type (null, void, short,
    long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode,
    longlong, ulonglong, longdouble, wchar) then equivalent() returns true.

    b) If the two TypeCodes are string, wstring or fixed with the same
    parameters (bounds, digits or scale) then equivalent() returns true.

    c) If the two TypeCodes are both arrays or both sequences, with the
    same bounds and their component types are equivalent(), then
    equivalent() returns true.

    d) If the two TypeCodes are both object references, return true if the
    their RepositoryIds are the same.

    e) If the two TypeCodes are both structs, exceptions, unions, enums or
    aliases, and they have the same RepositoryId, then equivalent() returns
    true. Note in this case that member TypeCodes are not compared.

    f) If either or both of the TypeCodes have an empty RepositoryId, then
    equivalent() falls back to a structural comparison, and returns true if
    all members of the two TypeCodes also are equivalent(). This case will
    only occur when interoperating with an older ORB that does not yet
    require RepositoryIds as mandatory for these TypeCodes. Note that the
    name() and member_name() fields are not used in this comparison.

    g) Otherwise, equivalent() returns false.

    6. The ORB uses TypeCode::equivalent for all internal TypeCode
    comparisons, such as for supporting any (and thus DII and DSI) and

    7. If the programmer needs to distinguish between a type and/or
    different aliases of that type, he can call TypeCode::id() and compare
    the RepositoryIds.

    8. All DynAny insert & get operations do not consider aliases as
    significant. The type() operation however, will return the TypeCode
    with all of the aliases intact, including type() from any DynAny member
    components. DynAny::assign() and DynAny::from_any compare the internal
    TypeCode of the DynAny with the TypeCode of its argument using
    TypeCode::equivalent() and raise Invalid if equivalent() returns false.

    9. The TypeCode::equal() operation is not used internally by the ORB
    and is deprecated.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT