I am studying COM so there're some basic questions puzzling me...
I know that IDL file is used to describe the method definitions (or the so called 'contract' between software modules), and the .H header files contains something like a method prototype, which looks similar to what the IDL is meant for. So, why are these two things coexist? Isn't one enough?
Many thanks.
Interface description language (IDL) is a small language in itself which provides a programming language independent way to describe an interface. Tools generate .h files from your .idl.
If you only had a .h file it would be impossible to tie into it with another programming language. .h files are very specific to C and C++ code only.
Some other differences are that in .h files you can sometimes have implementation as well as declaration, as well as class member variables. Whereas in IDL you are strictly defining an interface.
An interface description language (or alternately, interface definition language), or IDL for short, is a specification language used to describe a software component's interface. IDLs describe an interface in a language-neutral way, enabling communication between software components that do not share a language – for example, between components written in C++ and components written in Java.
On the other hand, .H files are used exclusively by the C/C++ compiler in order to generate code-object. So, they are language specific.
a .h file is a header file that allows inclusion of declarations of classes, structs and so on. It deals with compiler issues, and it deals with code that is local. On the other hand, when you have different entities that need to communicate, like in the case of CORBA, you need to handle data passing between entities that can be in different addres spaces, like two different programs running on the same computer, or even on different computers. All these programs can be written with totally different languages, yet they must be able to communicate. IDL allows you to define the interface these components export to the world through to the ORB communication channel. The level of component is higher than the level of classes. A component, to simplify, can be seen as an aggregation of classes performing a complex task.
IDL describes the interface of a software component in a language/platform independent way, delegating the task of realization to vendor specific tools. These tools convert the IDL definition into real classes (with their includes) for the callee, and a "stub" class that you can compile and link into the caller. The stub class exposes the interface of a remote callee service as defined in the IDL, but it does not perform any task except sending out the request to the remote service through the ORB and handling back the result to the caller.
Edit: on your answer in the comment
Thanks Stefano. So, IDL is nothing but another "standard" respected by various languages, and different IDL-aware languages have their own tools to understand the IDL file and convert it into a understandable format, such as a C++ header file containing the ORB class declaration. Am I right now?
Yes and no. IDL is a standard to represent an interface of a component, interface that is exported (among many other things) for inter-process communication. The OMG group (who is behind the standardization of corba and idl) also has mappings between idl concepts and the various languages: see http://www.omg.org/technology/documents/idl2x_spec_catalog.htm
You cannot say that IDL is a standard respected by a language. IDL is a high-level expression of something that you can do, painfully, by hand. You can think of it as the same concept between a high level language such as C, and a low-level language such as assembler. The compiler takes the C code and creates assembler code for the target architecture (x86, sparc, whatever). Similarly, the CORBA vendor (not the compiler vendor) provided tool that parses the IDL produces a language-specific results that allows you to skip coding boring CORBA low-level details.
Now, I don't know how it is for the COM world, but being COM a ripoff of CORBA (or so I've heard), the concepts should be the same.
IDL file can be compiled to produce a handlful of useful stuff.
You can get a header file and a C source file with interfaces and constants that you can use to implement the interfaces in your application or use already implemented interfaces in some else's implementation.
Also you can compile an IDL file into a type library which is a very useful thing in itself. You can import a type library into different languages to consume a COM object. You can include the type library into the COM server resources and this can give you Automation marshalling that will let you make in out-proc server out of an in-proc server without writing anything. You can also use ATL templates to have a late binding implementation in your COM server without writing anything if you have a type library in your COM server resources.