[omniORB] Question about unions and c++ mapping

[david.jobet at americas.bnpparibas.com ()]

Hello,

I have read the "Mapping for Union Types" available on the omg website
http://www.omg.org/spec/CPP/1.2/PDF/
(and honestly I'm not sure I understand it completly)

Here's an IDL I have to use :

enum MyEnum
{
myEnum1,
myEnum2
};

union MyUnion switch(MyEnum)
{
case myEnum1: LightweightObject lightweight;
case myEnum2: FatObject fat;
};

I don't have a control over it and I need to allocate a sequence of it
(possibly long).

Basically, this is what I would like to write : (#1)
MyUnion &union = seq[no]; // seq is a sequence of MyUnion
union._d(myEnum2); // oops, discriminant not initialized yet
FatObject &fat = union.fat();
initializeFat(fat);

But it does not work, the correct compliant way is : (#2)
MyUnion &union = seq[no]; // seq is a sequence of MyUnion
FatObject fat;
initializeFat(fat);
union.fat(fat); // initialize discriminant and performs deep copy

Is there any way to avoid the deep copy ? It can be costly if the sequence
is very long.
Is there any good reason the spec disallow writing code #1 ?

Looking at the code generated by omniidl, it would be completly possible
and safe to do it in the #1 way, but I would have to manually patch the
generated code to explictly allow it.
Any thought about it ?

Tx

David


This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20091230/7b54644d/attachment.htm

[Duncan Grisby]

On Wed, 2009-12-30 at 15:41 -0500, ***@americas.bnpparibas.com
wrote:

[...]

Post by david.jobet at americas.bnpparibas.com ()
Basically, this is what I would like to write : (#1)
MyUnion &union = seq[no]; // seq is a sequence of MyUnion
union._d(myEnum2); // oops, discriminant not initialized yet
FatObject &fat = union.fat();
initializeFat(fat);
But it does not work, the correct compliant way is : (#2)
MyUnion &union = seq[no]; // seq is a sequence of MyUnion
FatObject fat;
initializeFat(fat);
union.fat(fat); // initialize discriminant and performs deep copy
Is there any way to avoid the deep copy ? It can be costly if the
sequence is very long.
Is there any good reason the spec disallow writing code #1 ?

The mapping spec for unions is ugly in lots of ways, and this is one of
them. I don't know why there isn't support for what you want.

Post by david.jobet at americas.bnpparibas.com ()
Looking at the code generated by omniidl, it would be completly
possible and safe to do it in the #1 way, but I would have to manually
patch the generated code to explictly allow it.
Any thought about it ?

You're right, it could be done safely. You can either modify the
generated code or, if you feel like a more complete approach, modify the
omniidl back-end to generate different code. If you want to do that, let
me know so I can give you some pointers and help you do it in a way that
can be incorporated in the release.

Another thing that is probably relevant to you is that omniORB 4.1 (and
previous releases) sets aside space for all union members in some cases,
meaning that a lot of space can be wasted. Ages ago, Michael Teske sent
me a patch that partially fix that. I've extended / modified it to be
more efficient with storage in all cases, but I hadn't got around to
checking it in. Your post has prompted me to finally do so, so if you
get the current trunk from svn, you'll find the new mapping
implementation.

Cheers,

Duncan.