introduction
efficient and appropriate use of header files requires a few tricks. if you simply define a set of functions, everything works fine. no problems. if the file is included more than once because of a complex #include chain, you get redundant declarations. most compilers, including the microsoft c/c++ compilers, simply ignore these redundant function and variable declarations. however, if there are any class, typedef, struct, or some other declarations, the compiler will complain bitterly if they are seen twice, claiming they are duplication declarations. it does not choose to see if the structures actually are identical. so there is an idiom to avoid duplication declarations, which is to put the entire contents of the header file in an #ifndef, skipping the body if a symbol defined within the body is already defined. this works acceptably well for short files, but is a performance disaster for lengthy files, since each line of the file must be read. for standard header files, precompiled headers work well in eliminating this problem, but it is harder to justify putting your own headers into a precompiled header file since the effects of a simple change result in a massive recompilation (stdafx.h has to be recompiled). microsoft has added a #pragma that means the header file is read only once. all of this is shown in detail below.
dll headers: additional complexity
when constructing a dll, you need a header file to interface to it. however, the obvious solutions do not work as expected. for example, if you declare a function in a fashion so as to export it, you need to add __declspec(dllexport) to its declaration, and if you don't want name mangling, particularly important if you expect to use the dll with straight c code as well as c++, you need to define it in the .cpp file as
extern "c" __declspec(dllexport) function-header { // ... whatever }
the problem with this approach is that the obvious solutions to the header file don't work.
the first wrong approach
the first attempt you might make is to declare, in the .h file
extern "c" function-prototype; // incorrect
this doesn't work because the compiler will complain that the prototype is incompatible with the declaration. what causes this is the prototype lacks the __declspec(dllexport) declaration. so, you say, i'll just add that in. so you get
extern "c" __declspec(dllexport) function-prototype; // incorrect
this doesn't work for a different reason. although you will no longer get a warning when you compile the dll, you will get a warning when you compile the application, because the declaration __declspec(dllexport) is incompatible with the use of the function call.
the second wrong approach
at this point a couple workarounds present themselves. the first one you might consider is to use two header files, one of which has the __declspec(dllexport), and the other of which does not. this is a bad idea. the reason is that you lose the consistency checking you would get if you include the same header file into both the dll compilation and the client compilation. for example, if you change the function to have a different parameter type, the compiler will complain unless you change the dll's header file prototypes to correspond. but in this case, the dll header file is completely useless, and might as well not exist, because there is a completely separate header file for the client. it remains uncorrected, and there is no cross-check against the actual module. you lose.
