James Turner wrote:
> On 27 Jul 2008, at 16:41, Frederic Bouvier wrote:
>>>> you have no idea about the cruft windows.h is dragging.
>>> True. But I had the impression that you were adding the
>>> #if ... #include <windows.h> #endif  to every single file,
>>> anyway.  :-)
>> You are misinformed. I was adding config.h. Look at the CVS log for  
>> the
>> number I removed.
> A few observations:
>   - there are some *header* files which drag in config.h, which is a  
> major no-no. I'll get this one fixed
>   - header inclusion is a very very real compilation time issue,  
> especially for gcc since they're not shared (MSVC can do magic caching  
> I believe). As I have time / boredom, I'm going to start reviewing  
> header / source files in turn to do minimisation on their include  
> trees. This will basically mean removing all the includes, seeing what  
> breaks, and gradually adding them back in, but it's a bit more  
> scientific than that. The golden rule is headers should be independent  
> (pull in their dependencies) but minimal (not pull in anything they  
> don't directly need). I'm also going to see if there's places where  
> forward declarations in headers can replace actual includes.
If you're doing that work, I'd like you to follow a *really* minimalist stance 
i.e., if a header file only contains pointers or references to another class or 
includes them as arguments in uninstantiated templates (e.g., 
osg::ref_ptr<foo>), then that classe's include file should not be sucked in; a 
local class declaration should be made instead.

This will generate more work for you, but is really the way to go in terms of 
reducing compiler dependencies.

> - config.h is optional, but compiler.h is not, and still exists. In  
> the near future, the only thing it will do is silence some MSVC and  
> MipsPro warnings, but it's still there, and can be hooked for other  
> things. Generic includes of *heavy* headers is definitely not the way  
> to go.
> And a question:
> - The sources erratically alternate between using the C-library  
> wrappers and not, i.e include <stdio.h> vs include <cstdio>. Is this  
> worth fixing, aside from neat-ness? AFAIK on every system <cstdio> is  
> just a straight wrapper around stdio.h, so it's a not very useful and  
> extremely noisy (in CVS) change to fix every <string.h>, <stdio.h>,  
> <stdlib.h> and so on. Opinions on doing this
In C++ code they should be <cstring> and friends in order to ensure that the 
functions are all declared in the std namespace.


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Flightgear-devel mailing list

Reply via email to