[omniORB] Using #include in IDL files

[David Morgenlender]

>I understand the problem.  Anyone who programs on Windows will likely
>encounter the same problem when trying to make a CORBA entity understand
>certain GUI data structures, enums, etc.  We opted for your first
>solution (enter the structure in IDL).  This results in the need for
>proxy objects to obtain interoperability between the native Windows
>struct and the CORBA struct.  Sometimes this is a pain but it is
>manageable.=20

Only automated solutions are adequate in this case.  The struct in =
question
contains appoximately 150 fields, which are likely to change!

> In cases where you don't have a predefined struct or enum
>definition thrust upon you, you can create an IDL with nothing more than
>the struct or enum definition, submit it to the IDL compiler, and then
>use the generated header in your C++.  This may well be the gross kludge
>you alluded to, but it is less gross than at first glance.  This method
>helps enforce synchronization between IDL and C++ source.

Nope, that's not the kludge.  But it might be usable, if it can be =
automated in
VC++.  I forget if I ruled out that approach or just didn't think about =
it;  the
answer to that should be in my notes. =20

The biggest problem this app faces is the struct must be usable by COM, =
as well
as CORBA.  The COM IDL compiler does a nice job of handling the =
#include'd
header file, which describes the struct.  One part of the app is a =
"mediator"
which converts between COM & CORBA.  Because the struct is used by both =
COM &
CORBA, and I wanted to avoid data conversions at all costs, all data =
types are
compatible between COM & CORBA, although the data types may have =
different
names, and there are some clever little tricks (which are maintainable!) =
to
handle things like a bool being 1 byte on one side & 2 bytes on the =
other.  The
nature of this app is such, that these data type restrictions do not pose=
 a big
problem.  Among other things, there are no data types, which are actually
pointers to other objects (e.g. strings).  Thus the kludge ... the struct=
 is
passed thru CORBA as an array of bytes!!!  The conversion between struct =
& byte
array (which requires no knowledge of the struct definition, only the =
size) is
all handled by low level code, so the app itself is not aware of it.  =
There are
some conditionally compiled error checks to minimize (not eliminate) =
chances of
a problem which would be detected by type checking.  So far, the only =
such
problems have been detected by these error checks.  IAE, the kludge has =
been
working fine for many months now.  The build is automated.  But, I'd =
still
prefer a clean solution!

>I think a lot of this kind of problem may stem from the difference
>between an application which has been designed with CORBA from the
>start  and an application which might have CORBA added later or added as
>an optional or auxilliary attribute (neither of these cases being better
>or worse than the other).  Putting a CORBA application on Windows will
>generally fall under the second case, even if it is a new application
>because of Microsoft's penchant for being CORBA-unfriendly and forcing a
>lot of predefined, immutable, and proprietary *stuff* down Win32
>programmer's throats.

As I describe above, none of this describes my situation.  Sure there are=
 some
immutable rules in COM.  But the ones in question here are equivalent to =
those
in CORBA.  Overall, I've found CORBA to be much more friendly than COM.  =
But in
this case, COM wins!

>I would hate to see the IDL get bogged down with a lot of #pragma's
>(probably the only way to solve this problem).  It may, however, be
>inevitable.

Actually, all that is needed is an "import" (or whatever you want to call=
 it)
statement AND a #include statement.  One does what the IDL compiler does =
now;
the other is a straightforward preprocessor include.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Dave Morgenlender
e-mail: dmorgen@alum.mit.edu
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D