[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.