[omniORB] Corba union waste of space?

[Bruce Visscher]

On Mon, Dec 8, 2008 at 6:18 AM, Duncan Grisby <duncan at grisby.org> wrote:
> On Thursday 4 December, Michael Teske wrote:
> [...]
>> 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?).
>
> The String_members cannot go in the union, because you can't put such
> things in a C++ union. It certainly would be possible to store pointers
> to String_members (and other complex types) instead, and they could go
> in the union. I'd welcome a patch that did that.
>
> The place to start attacking it is to look in
> src/lib/omniORB/omniidl_be/cxx/header/template.py which defines the
> templates that go in the C++ headers. From there, search the code for
> the places that use the templates. I'm afraid that some of the C++
> back-end code is rather ugly...

Thanks Duncan.

Michael, one thing I would suggest (inspired by Teemu's post) is that
if you are going to spend the time doing this you consider an
implementation that utilizes placement new and explicit calls to the
destructor (as boost variant apparently does).

A brief outline would be (using String_member as an example) declare a
char array[sizeof(String_member)] as a union member.  Also declare
(but do not use) something with maximal alignment requirements
(void*'s and/or long long are good choices you could actually use
both).  This would ensure that the storage will be aligned on a 32 or
64 bit boundary.  Then use placement new to initialize the storage and
an explicit call to the destructor "deinitialize" the storage.  This
would avoid an extra memory allocation.  Use
reinterpret_cast<String_member*> on the char pointer in the
String_member accessor.

Just a thought,