[omniORB] Using #include in IDL files

[Steven W. Brenneis]

David Morgenlender wrote:
> 
> On Mon, 10 May 1999 23:40:13 -0500, you wrote:
> 
> >I thought a long, long time before replying to this, but the longer I
> >looked at it the more it bothered me.
> >
> >Why would you mix C++ and IDL?  IDL is intended to define a platform and
> >language independent interface.
> 
> Here's one reason why ... I ran into a similar problem with a struct.  There are
> many parts to this app, which require the struct definition;  some of these are
> not involved with CORBA.  I want there to be a SINGLE definition of the struct;
> otherwise, it's a maintenance nightmare.  The struct must be defined within the
> IDL file;  however, if I #include the .H file, the IDL compiler mishandles it,
> thinking it must be an interface definition.  So I'm left with the choice of
> manually entering the struct definition in the IDL file or using some kind of
> gross kludge;  either of these choices is ugly!  (BTW, I'm using the gross
> kludge approach.)
> 
> My feeling is that if the IDL compiler must require knowledge that an include is
> of an interface definition, it should also provide a way to do a straight
> preprocessor include.
> 
> =======================================================
> Dave Morgenlender
> e-mail: dmorgen@alum.mit.edu
> =======================================================

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

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.

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.