Why many header files are incomplete?

  If a header file defines a function/macro that needs another function/macro
in another header file, it could be expected that this header file would
properly include that another header file.
  Some header files are even illegal. For example, if I make this:

#include "mem.h"
#include "frame.h"

I get an error:

mem.h:56: parse error before `size'

  If I change the order of the includes:

#include "frame.h"
#include "mem.h"

then the error goes away.

  Do I need to comment anything to this that is not clear by itself?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <3a335eb3@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Why many header files are incomplete?

because of the cross-platform support and adjustments that have to be made
in config.h!  I.e. you can change the default memory management, and you
need to include config.h somewhere, that is why there is the simple rule to
*always* include frame.h first.


     Thorsten

Post a reply to this message

In article <3a335eb3@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   If a header file defines a function/macro that needs another function/macro
> in another header file, it could be expected that this header file would
> properly include that another header file.

Without precompiled headers or similar compiler features, it would then take
much, much longer to compile POV-Ray.

Further, it would again cause many, many problems of name scope (remember,
this is not C++!).  frame.h defines a lot of internal macros with rather
generic names (I don't defend this, it is just the way it is until the
rewrite), so if a platform specific file needs some core include file but
not frame.h or another related include file, or needs them in a particular
order, you can have numerous name collisions!


    Thorsten

Post a reply to this message