On Aug 11, 2008, at 7:37 AM, Paul Aitman (Work) wrote:
> The trouble is Windows also defines these as global macros in
> various files including the WinDef.h file, so other header files
> which assume their existence (not many of them admittedly) may no
> longer compile depending on order of #includes I guess.
So, do you have a solution in header reordering, or are there
combinations that simply do not work? If you can't make it work, we
can talk about adding conditional code in common.h to avoid the
undefs. Before I do that, I have to see code that can't be made to
work any other way. These undefs really are necessary in some
situations, so I won't just remove them.
I find that ordering the headers like so presents the fewest problems:
- module header (i.e. foo.c always includes foo.h first, even if it
doesn't actually use anything from foo.h, to give the compiler the
chance to check that declarations match definitions)
- project-specific headers
- headers for personal convenience libraries (i.e. stuff I've built
myself, but compiled into separate libraries)
- third-party library headers
- OS headers
- C++ standard headers
- C standard headers
When in doubt, always put the header for the library with the highest
level of abstraction first.
A side benefit of this scheme is that it means you need fewer of the
includes toward the bottom, since the higher-level headers pull in C, C
++ and OS headers themselves, so the ones needed by the module usually
get pulled in implicitly. For example, I rarely need to #include
<stdlib.h> in a .cpp file, since I can usually count on it to get
pulled in by some other header.
