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. Tim ------------------------------------------------------------------------- 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
