Re: Where/when to #import
Re: Where/when to #import
- Subject: Re: Where/when to #import
- From: Jonathon Mah <email@hidden>
- Date: Wed, 10 Oct 2007 03:13:34 +0930
Hi Paul,
On 2007-10-10, at 00:55, Kai Brüning wrote:
There are actually two reasons I know about why you may want to use
@class (that is, a forward declaration) instead of #import if
possible:
- To avoid circular references (as Etienne points out in his
answer), which is a rare problem.
Indeed. The whole point of using #import instead of #include is to
have the compiler avoid circular references automatically. It does
this by not re-including a file if another of that name has already
been imported.
You can still get duplicate imports if, for example, you have a
structure like:
// ClassA.h
#import "other/ClassB.h"
#import "ClassC.h"
// ClassC.h
#import "ClassB.h"
Since it only works on the path level, ClassB.h would be included
twice (which would likely lead to errors).
But in more recent versions of Xcode, this is mostly a moot point,
since you don't usually have to specify a path to a file -- Xcode will
put all the directories containing headers on the include path
automatically.
- To minimize imports in headers in order to speed up compiles.
This is the real reason you'd want to use @class instead of #include.
If I may tweak Nelson's rules:
1. Generally, #import <Cocoa/Cocoa.h> in your class interface files.
For model classes that you might want to use in non-GUI situations
(e.g. Spotlight importer), you can instead just #import <Foundation/
Foundation.h>.
(Importing Cocoa.h is shorthand for importing Foundation+AppKit
+CoreData.)
2. If your class interface refers to other classes that aren't in the
frameworks (such as in instance variables, or method parameters and
return types), forward-declare those classes with @class.
3. If your class is a subclass of a non-framework class, you must
#import the superclass's header.
4. In your implementation file, #import the interface, and #import the
interfaces of any other classes whose methods you call.
The situation you want to avoid is this. Say you have a class that is
used by many other source files in your program (CommonClass), and its
interface #imports a little helper class (HelperClass). If you tweak
HelperClass.h (re-order instance variables, or even just add a
comment), then that will flow on to CommonClass.h, which will then
flow on to the hundreds of other files that include the common class
(making the build take a long time). Instead, the /implementation/
CommonClass.m should #import HelperClass.h, and CommonClass.h should
just @class HelperClass.
And I've written a bit too much now.
Jonathon Mah
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden