[omniORB] Using #include in IDL files

[Steven W Brenneis]

James M Moe wrote:
> 
> Hello,
>     Before you say anything, Yes, I did search the archives about this. The suggestion
> I use is the one with the preprocssor.
>     It is not an ideal solution, though it is workable.
>     What we are doing is using a common header between IDL and c/c++ files for
> enumerations. In this way changes in the enumerations propogate through all the code.
> Also the files are not actual code, only the parts that reside inside of enums:
> 
> IDL:
>     enum enumT {
> #include "foo-bar.h"
>      };
> 
> C++:
>     typedef enum _enumT {
> #include "foo-bar.h"
>      } enum_t;
> 
>     There are 3 annoying aspects to the way omliidl2 works regarding #includes:
> 
> 1. Without preprocessing the #include'd text is processed (correctly inserted in to the
> stream) by the IDL compiler, and then also #include'd in the output .hh file with a
> ".hh" extension instead of ".h". Sheesh!
> 
> 2. If the header file uses hyphens in the name, eg: foo-bar.h, a (seemingly incorrect)
> inclusion guard is generated like this: #ifndef foo-bar_HH_other_stuff. The main
> compiler then barfs on the #ifndef since it seems to think there is a defective
> arithmetic operation.
> 
> 3. The generated code is different between using CPP and not, if there are actual IDL
> files also being included. Without CPP the included IDL is used as material to resolve
> missing or ambiguous references. No code is generated for the included files except of
> the #include <stuff.hh> sort.
>     When the file is run through CPP, the IDL compiler gets a file with the full text
> of the included IDL files so generates code for those also. No #include <> statements
> are needed since the whole wad is there.
> 
>     Is this behavior defined by the CORBA spec? If not, are there plans to smarten
> omniild2 so it can better deal with these exotic styles?
> 
> Jim Moe

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.  I'm not sure what else you are doing
with this enumeration, but with the information you have given us you
could accomplish the same result with:

IDL:

module Jims_enum {

enum enumT { foo, bar };

};

C++:

#include "Jims_enum.hh"

typedef Jims_enum::enumT enum_t;

If you really need the enumerations to be in the global namespace (not
generally a good idea) and you have an ANSI-compliant compiler, you can
add a:

using namespace Jims_enum;

If your compiler does not support namespaces, you can leave the
Jims_enum module declaration out of the IDL and the Jims_enum scope out
of the C++.

With regard to item 2, I think you must be using an older version of the
IDL compiler.  I sent David Riddoch a note on this and he fixed it (I
think in version 2.7.0, David can correct me if I'm wrong).  I am
currently using version 2.7.1 and my IDL file names have all sorts of
characters the preprocessor wouldn't like in a header guard, including
dashes.  I'm pretty sure they are all replaced with underscores.

In item 3, I can't be sure but it almost sounds like you are submitting
IDL to the C++ compiler and C++ to the IDL compiler.  Is this the case?

Lastly, the IDL compiler has to generate relatively brain-dead include
statements in the stub since it has to assume that you included external
IDL's for a reason.  OmniORB IDL does a great job of making this
intelligent as possible.

Hope this is helpful.

Regards,
Steve Brenneis