It is entirely possible (and sometimes useful) to #include headers in a local context.
The problems are not only understanding them, but that a header really only works well in a global context.
Consider the following header:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
|
#pragma once
#ifndef FOOEY_HPP
#define FOOEY_HPP
#define QUUX 42
namespace barf
{
int eat( int );
};
extern int zog;
#endif
|
If you include it in the global context (as you should), then you can use its contents anywhere within your source file. If you include it in a local context, you are spilling macro definitions into the global context, and making it so that you cannot include the file again in
any other context in the same source file.
More advanced header files may actually
fail when inserted in a local context. (Just about anything from Boost comes to mind.)
Moreover, you could easily create linkage problems with local #includes.
So when is a local include useful? I would say "never", but it is possible that you may wish to adjust some local piece of information through external resources. For example, a local table generated by another program would be ideal to locally #include. We remember, of course, that said header was specially designed to be locally #included in
one spot.
Even in that case, though, C++ gives you many ways to avoid such a construct. (Depending on what you are doing in C, you may or may not want to do it.)
Finally, the problem with such things is that your files know too much about each other -- source encapsulation spills out to the preprocessor and linker, instead of staying within the compiler proper. This becomes a significant problem when porting code to other platforms.
Hope this helps.