[omniORB] #include in .IDL file works incorrectly!!!

[David Morgenlender]

Sai-Lai,

>I guess what you are trying to do is something like this in pure OMG =
IDL.
>
>// File     S.IDL
>// OMG IDL
>struct X {
>  string A;
>  char   B;
>};
>
>
>// File     MAIN.IDL
>#include "S.IDL"
>
>interface I {
>   X op();
>};

Almost:

1.  I'm doing:

	typedef struct ...

But I could live with the way you have it.

2.  The struct is being used as a parameter type, not a return value.

>The complication is you want the definition of struct X to be done in a
>single source file for both COM and CORBA.
>
>1. Remember, the IDL compiler handle all the #include files only as IDL
>   files so any C++ specific constructs in the files would not be
>   recognised.

That's not a problem given the nature of this particular struct.  Among =
other
things, all variables must be fixed length ... so no "string", =
variable-length
array, etc.

>2. I suppose it is a bug that the compiler translate something like =
this:
>
>     interface I {
>     #include "S.IDL"
>        X op();
>     };
>
>   into
>     #include "S.hh"
>
>     class I {
>        ....
>     };
>
>   Hence relocate the #include out of the context it is used in the IDL.
>   However, it is difficult to detect this and generate #include in the
>   output at the right context.

This bug is annoying, but not fatal.

>3. I don't know if I have an answer to achieve what you want.
>   One possibility may be to define a single IDL file with appropriate
>   #if to separate OMG IDL specific and COM IDL specific part while
>   sharing as much as possible.=20

The difference between this & my solution is that in my solution, the
differences are handled by using typedef (& possibly #if) in the invoking=
 source
file, while your approach puts everything in the #include'd file, except =
the
#define's.  However, both approaches have problems with the way the =
compiler
currently works:

The compiler generated incorrect code, e.g. in the .HH file:

  a.  The #include statement is put at the front of the .HH file, while =
the
typedef is placed later, AFTER the #include, which requires it.

  b.  The #include is for x.HH, which is not generated by the compiler & =
does
not exist. =20

  c.  There is no #include for x.H.

  d.  The struct definition does not exist for any source file created by=
 the
compiler!  It's not in any compiler output file.  It's only in the =
original .H
file ... but this is not #include'd anywhere.  So the compiler-produced =
source
files will not compile!  Neither will any application source file, which
#include's the compiler-produced header files.

  e.  Any #define in the main .IDL file is lost!  My playing around with =
it, I
was able to determine the compiler used it when processing x.H.  However,=
 it's
totally lost after the IDL compilation!

  f.  The typedef in the main .IDL file is not lost.  However, it is =
placed in
the main .HH file AFTER the #include of x.HH, where it doesn't do any =
good.

I can kludge around the problems both in my application source code & the
compiler-generated sourse code. =20

  a.  I can create a dummy x.HH file, which is already #include'd by the
compiler-generated files & will be #include'd by my app.

  b.  The dummy x.HH file will redundantly have the relevant typedef's &
#define's as are in the main .IDL file.

  c.  The dummy x.HH file then #include's x.H.

But even this still has a problem.  There is now a redundant typedef:  =
the one I
put in x.HH & the one the IDL compiler puts in the main .HH file in the =
wrong
place.  I'm not sure if this will cause a C++ compiler error.

I may be able to get tye typedef problem by using redundant #define's =
instead.

I think my approach covers everything else;  but haven't tried it.  IAE, =
it's
VERY kludgey.  It requires redundant #define's, which I hate to do, since=
 it
tends to lead to future errors.

Do you think this will work?  Do you have any better suggestions?


-------------------------------------------------------------------------

I've thought of one other strategy, which avoids all the CORBA issues, =
but is
somewhat ugly.  On the COM side, I really need to use the #include in the=
 .IDL
file;  this allows any COM client to use the struct, whether it be C++ or=
 VB,
without any redundant struct definitions, such as in VB.  In the CORBA =
server
application I also want to use the same .H file for cleanliness & =
avoiding
future errors. =20

However, I can take a different approach when handling the struct between=
 COM
server & client.  I can pass the struct as a fixed-length array of bytes.=
  I can
layer functions, such that the COM server application code never sees the=
 kludge
... it will #include x.H & just see structs as calling parameters.  The =
IDL file
never sees a definition of the struct.  My interface code on the COM =
server can
at least insure the size of the array matches the expected size of the =
struct to
reduce, but not eliminate, the chances of use of inconsistent struct
definitions, etc.

Opinions?

=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