[omniORB] Corba union waste of space?

[Michael Teske]

Bruce Visscher schrieb:
> 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,

Hi Bruce, hi Duncan,

this sounds resonable, so I think I'll do it this way, but it might take 
a while since I go on vacation next week.

Greetings,
   Michael