From: Warren Young Date: August 11 2008 5:40pm Subject: Re: VS-2005 (32bit) Compile Problem List-Archive: http://lists.mysql.com/plusplus/7842 Message-Id: <453658D8-5043-46B1-9417-028CF6243161@etr-usa.com> MIME-Version: 1.0 (Apple Message framework v928.1) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 in a .cpp file, since I can usually count on it to get pulled in by some other header.