discuss-gnustep
[Top][All Lists]
Advanced

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

Re: an error from the expression: CLS_ISCLASS((Class)receiver) File: sen


From: Richard Frith-Macdonald
Subject: Re: an error from the expression: CLS_ISCLASS((Class)receiver) File: sendmsg.c Line 321
Date: Fri, 13 Feb 2009 13:53:46 +0000


On 13 Feb 2009, at 12:31, David Chisnall wrote:

On 13 Feb 2009, at 08:30, Truls Becken wrote:

The other point I'd like to make is that importing <AppKit/AppKit.h>
in AppController.h would simplify things a bit. I guess it's debatable
whether this is better than declaring/importing only what is strictly
needed in the header and then import AppKit in the implementation
file, like you do now, but generally I think it's simpler to just
import AppKit in the controller header and be done with it. This would
replace the 5 classes you currently declare/import - a list which
would surely grow as you develop you application.

The rationale for not #importing AppKit.h is that it is huge. The preprocessed header is over 700KB (just under 36,000 lines), which means that the compiler has to build a parse tree that is likely to be several MBs before it even gets to your program.

This is worked around on OS X by using prefix headers. These are preprocessed and pre-parsed headers that are used automatically in place of Cocoa.h (which, with GCC, has around a 30MB parse tree). This is one of the main reasons why OS X programs use Cocoa.h rather than AppKit.h and Foundation.h - you are only allowed one precompiled header per program.

I don't know if GNUstep make has support for precompiling Cocoa.h. If not, it might be worth adding, since it can reduce the memory usage and processing time of a big build.

I know GNUstep-make supports precompiled headers, but I don't think it does Cocoa.h It's not clear to me where Cocoa.h would be found/provided in the GNUstep packages.





reply via email to

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