On 18 Feb 2010, at 08:55, Richard Frith-Macdonald wrote: > It generally doesn't matter much, but I've just gone for considering all > internal headers as objc unless they clearly have to be plain C. > In fact I should probably not have made the C/ObjC distinction since there is > really no such clear definition, and what we are really concerned about is > whether the header is meant to be included *once only* or to be included > multiple times in the same file. The vast majority of headers are in the > first category.
Most C headers will work correctly with #import, but a few are designed to support multiple inclusion. For internal GNUstep headers, it doesn't matter, it's just a bad habit to get into, because eventually you'll come across that one C header that doesn't and then spend ages trying to work out why it's breaking. > Sounds reasonable ... I had no idea that support for precompiled headers was > still missing on most systems. It's worth noting that separate includes do not preclude the possibility of using precompiled headers. I'm not sure about the GCC implementation (it seems to be an ugly hack), but in Clang, a precompiled header is basically a serialised AST of the file. If you generate a precompiled header for Foundation.h and then use it as a prefix header in a file that just #imports NSObject.h, as long as the search paths are the same the compiler will skip over NSObject.h. > I'm not convinced by the other part of the argument (about precompiled > headers not being much faster), since I would expect proper support to cache > the precompiled headers (disk space is cheap) so that there would be a big > gain for some people (obviously this would vary with your pattern of use). > But an argument about performance with precompiled headers is completely > irrelevant if most people just don't have support for them. It's a big win for Apple because I/O is slow and process creation is expensive on OS X. On Windows it's probably a win too - process creation is very expensive. It's less clear on *NIX, where process creation is relatively cheap, and with flash the reduced number of random disk reads is not such an issue. It's also worth noting that our Cocoa.h is a LOT smaller than Apple's. The output from gcc -E on a simple .m file that just contains the line #import <Cocoa/Cocoa.h> is around 800KB on GNUstep and over 3MB with Cocoa. The speed benefit from PCH is directly proportional to the size of the prefix header and, to a lesser degree, to the number of files referenced by the prefix header. David -- Sent from my PDP-11 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
