Resources | Resources |



Include directives and code generation

Many IDL files include other IDL files in order to make use of types and interfaces declared externally. For example, when defining an OS Services interface in IDL, AEEIQI.idl needs to be included for the definition of IQI, from which all CS interfaces must derive. However, one important difference between #include in IDL and #include in C/C++ is that in IDL, code is not generated for modules, interfaces, and types included from other IDL files. For example, consider the following IDL:

interface IFoo : IQI { /* definition of IFoo here */ }; 
interface IBar : IFoo { /* definition of IBar here */ }; 

If this IDL is compiled, the output will contain the appropriate code for both IFoo and IBar. However, suppose the IFoo definition is moved to AEEIFoo.idl, and the IDL being compiled is changed as follows:

#include "AEEIFoo.idl" 
interface IBar : IQI { /* definition of IBar here */ };

In this case, only code for IBar will be generated. Although the contents of AEEIFoo.idl are read by the compiler, no code is generated for IFoo because it is defined in an external (included) IDL file. Instead of generating code for IFoo, the compiler will translate the #include in the IDL to a #include in the output, with the extension changed from ".idl" to ".h". An example, which uses the C++ mapping, is shown below. For brevity, IID constants are not included in this example.

Input file: AEEIFoo.idl Input file: AEEIBar.idl

#include "AEEIQI.idl"        #include "AEEIFoo.idl"
interface IFoo : IQI                  interface IBar : IFoo
{                                     {
    AEEResult op1();                      AEEResult op2();
};                                    };

Output file: AEEIQI.h Output file: AEEIBar.h

#include "AEEIQI.idl"         #include "AEEIFoo.h"
class IFoo : public IQI                struct IBar : public IFoo
{                                      {
public:                                public:
    virtual int CDECL op1() = 0;           virtual int CDECL op2() = 0;
};                                     };

C header generation

C headers for OS Services are generated to resemble hand-written headers. For each interface name in IDL, an INHERIT_name macro is generated, followed by a call to the AEEINTERFACE_DEFINE macro to define the interface. Static inline accessors are also generated for each method.

C++ header generation

The C++ headers generated for OS Services look similar to the source IDL, since C++ has native support for namespaces and classes. Tthe C and C++ mappings are designed to be binary compatible, so there is no need to generate C++ stubs and skels in addition to the C stubs and skels. However, this means that C++-only header generation is not possible when remoting is required, since the C stubs and skels require the C header. Consequently, the -mc (C++-only) option is only permitted if remoting code generation is also disabled (-nr). When both C++ and remoting is desired, use the default -mcxx mapping option to generate a header that works for both C and C++.