[omniORB] omniidl (2.8.0 pre-release 1) Bug?

[Ken Feuerman]

This patch does the trick, of course.  Thanks for the quick response (and
pardon my lack of one!).

--Ken Feuerman.


At 11:50 AM 8/9/99 +0100, Sai-Lai Lo wrote:
>>>>>> Ken Feuerman writes:
>
>> Suppose I have the following IDL:
>> // idltest.idl:
>> module M
>> {
>>     interface A
>>     {
>>         typedef short Arr[4];
>>         void meth(out Arr arrayArg);
>>     };
>
>> };
>
>
>> When building under MSVC++ 5.0, I get a compile-time error:
>
>> idltest.h(106) : error C2027: use of undefined type 'A'
>
>> The compiler error is referring to a C++ typedef for Arr_out in the
>> generated header.  If I modify the IDL so that the definition of Arr is
>> outside the scope of A, the compiler error goes away.
>
>> This problem did not exist with omniORB 2.6.0; I have not tried this with
>> omniORB 2.7.x.  Is this a bug with omniidl, or with the compiler?
>
>This is a "bug" in omniidl2 (2.8.0pre1 only) because it forgets to
>workaround a bug in MSVC++. Try this patch:
>
>
>% diff -c omniORB_280pre1/src/tool/omniidl2/omniORB2_be/o2be_array.cc
new/src/tool/omniidl2/omniORB2_be/o2be_array.cc 
>*** omniORB_280pre1/src/tool/omniidl2/omniORB2_be/o2be_array.cc   Fri Jun
18 21:48:41 1999
>--- new/src/tool/omniidl2/omniORB2_be/o2be_array.cc Mon Aug  9 11:43:15 1999
>***************
>*** 1063,1069 ****
>      ubname = tdef->fqname();
>    }
>    else {
>!     ubname = tdef->unambiguous_name(used_in);
>    }
>  
>    char* p = new char[strlen(ADPT_CLASS_TEMPLATE)+strlen("<, >")+
>--- 1063,1069 ----
>      ubname = tdef->fqname();
>    }
>    else {
>!     ubname = tdef->uqname();
>    }
>  
>    char* p = new char[strlen(ADPT_CLASS_TEMPLATE)+strlen("<, >")+
>
>
>
>
>
>
>
>-- 
>Sai-Lai Lo                                   S.Lo@uk.research.att.com
>AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
>24a Trumpington Street                Tel:   +44 1223 343000
>Cambridge CB2 1QA                     Fax:   +44 1223 313542
>ENGLAND
>
>
>
>