[omniORB] Array Return Values and _var's
Ken Feuerman
kfeuerma@adobe.com
Thu, 26 Jul 2001 09:57:31 -0700
Suppose I have the following IDL:
interface TestObj
{
typedef long Larr[3];
Larr Method(in long param);
};
I would like to implement the Method() as follows:
TestObj::Larr_slice* Method(CORBA::Long param)
{
TestObj::Larr_var result = TestObj::Larr_alloc();
for (int i = 0; i < 3; ++i)
result[i] = param; // (***)
return result._retn();
}
The problem is that when compiling under MSVC 6.0 on Win2K, the line marked
(***) is flagged with the following compiler error:
error C2666: '[]' : 3 overloads have similar conversions
I've discovered three possible workarounds, each of which have their drawbacks:
1. Declare result to be TestObj::Larr_slice* instead of TestObj::Larr_var,
and return result directly at the end. The drawback of course is that if I
throw out of this method, I leak. (I might throw because someday the
Method will be doing actual useful stuff between Larr_alloc() and _retn().)
2. Replace the (***) line with
((TestObj::Larr_slice*)result)[i] = param;
The drawback is an ugly looking cast that obfuscates. Furthermore, I'm
relying on the "operator TestObj::Larr_slice*()" conversion operator that
happens to be defined in the omniidl-generated stubs; is this operator part
of the CORBA C++ mapping?
3. Use ORBacus instead, which doesn't seem to have this problem. The
drawback is of course that I wouldn't be using omniORB!
By the way, I happen to be using the July 11 snapshot of omniORB4, in case
that matters. Am I trying to do the Right Thing regarding the memory
management? Is this an omniORB (or, to be fair, an MSVC 6.0) bug? Of all
the workarounds, I'm leaning toward 2, provided I can be sure of using the
correct operator to get at the underlying array slice pointer.
Thanks for your advice!
--Ken Feuerman.
Adobe Systems, Inc.