My rule is that a header should include whatever headers are needed in order to use what is declared in that header.
For example, if it is impossible to use "graphics.h" without including "windows.h", then "graphics.h" should include "windows.h".
But I would also say a file that includes "graphics.h" shouldn''t use anything that isn''t declared in "graphics.h", or is absolutely necessary for using "graphics.h". That''s because, as mentioned before, if you change "graphics.h" so that it doesn''t need "windows.h" anymore, some files that use "graphics.h" might break.
One possible, although slightly unpleasant, way to ensure that you don''t accidentally use features that aren''t actually declared in the headers you''ve included could be to #include them into a namespace and then using the names you
need to make available:
namespace _win32{#include <windows.h>};using _win32::CreateWindow;using _win32::GetWindowRect;
I realise that''s ugly, and may be more work than you want to put in. It also means that you must always access the members of "windows.h" via _win32::, since #including windows.h again will just be ignored.
It''s perfectly safe to declare the same namespace twice, so it''s okay if "graphics.h" and "network.h" both #include "windows.h" into the _win32 namespace.
Note that, under this scheme, files should never access the members of _win32 directly unless they''ve also declared the namespace. Otherwise, you have the same problem you had before: if a header stops providing _win32, the including file breaks.
CoV