[omniORB] Corba union waste of space?

[Michael Teske]

Hi,


please conside this file testunion.idl :

--- snip ---


module test {
  enum DataType {
    StringType,
    CharType,
    CardinalType,
    IntegerType,
    PriceType,
    VolumeType,
    QuantityType,
    DateType,
    TimeType,
    StringArrayType
  };

  typedef string _String;
  typedef char _Char;
  typedef unsigned long _Cardinal;
  typedef long _Integer;
  typedef string _Price;
  typedef string _Volume;
  typedef string _Quantity;
  typedef string _Date;
  typedef string _Time;
  typedef sequence<string> _StringArray;

  union TheTestUnion switch (DataType) {
    case StringType:
      _String StringData;
    case CharType:
      _Char CharData;
    case CardinalType:
      _Cardinal CardinalData;
    case IntegerType:
      _Integer IntegerData;
    case PriceType:
      _Price PriceData;
    case VolumeType:
      _Volume VolumeData;
    case QuantityType:
      _Quantity QuantityData;
    case DateType:
      _Date DateData;
    case TimeType:
      _Time TimeData;
    case StringArrayType:
      _StringArray   StringArrayData;
  };
};

--- snip ---

When I compile it with omniidl -bcxx, it genedates the following C++ code in the
private: section of "class TheTestUnion" in testunion.hh:

 private:
    DataType _pd__d;
    _CORBA_Boolean _pd__default;
    _CORBA_Boolean _pd__initialised;

    union {
      Char _pd_CharData;

      Cardinal _pd_CardinalData;

      Integer _pd_IntegerData;


    };


    ::CORBA::String_member _pd_StringData;

    ::CORBA::String_member _pd_PriceData;

    ::CORBA::String_member _pd_VolumeData;

    ::CORBA::String_member _pd_QuantityData;

    ::CORBA::String_member _pd_DateData;

    ::CORBA::String_member _pd_TimeData;

    StringArray _pd_StringArrayData;




This seems like a bug (waste of space) to me or is there any reason that the
string members do not go into the union? Our real-life used union has even more
types... As I mentioned in an earlier post, we're porting our system from orbacus,
which uses pointers here so they fit into the C++ union data type (I suppose the
complex types are not allowed in a C++union?).

Greetings,
  Michael