gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: includes/imports in gui.


From: Richard Frith-Macdonald
Subject: Re: includes/imports in gui.
Date: Thu, 18 Feb 2010 08:55:15 +0000

On 17 Feb 2010, at 08:25, Fred Kiefer wrote:

> BTW the first file I checked in base for the new include style was
> NSThread.m and this hasn't been corrected at all :-)

Thanks ... I fixed that one.


>> Hopefully, I've now pretty much standardised on #include for C and
>> #import for ObjC.
> 
> Fine by me, but what do we count as being C? gui currently sees the
> config.h file as C and therefore we use #include.

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.

>> Anyway, given that gnustep-make and recent compilers have supported
>> precompiled headers for some time now, I think gui/back should
>> probably simplified to just do #import <Foundation/Foundation.h> 
>> (assuming that 'startup' installs base before it builds gui ... so
>> the installed Foundation.h will point to all the right code and will
>> have a precompiled version to make for fast compilation of gui and
>> back).
> 
> Here I agree with Nicola. Support for pre-compilation is not that
> widespread that we should enforce it. And including Foundation.h instead
> of single header files could make compilation slower in some cases. I
> think, in this case I will leave the gui includes just as they are, when
> we include Foundation.h fine, when it is broken up in single files, fine
> as well.

Sounds reasonable ... I had no idea that support for precompiled headers was 
still missing on most systems.

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]