Re: includes/imports in gui.

[David Chisnall]

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