Re: Where/when to #import
Re: Where/when to #import
- Subject: Re: Where/when to #import
- From: Tim Davis <email@hidden>
- Date: Tue, 9 Oct 2007 15:41:54 -0400
Uh Oh...
I've been reading this thread and I just realized that I must be
doing it all wrong....
I have several custom class.....
ClassA
ClassB
ClassC
and in my MainController.h file I have imported all of them via
"#import <classname>.h"
How exactly should I really be doing it?
On Oct 9, 2007, at 1:43 PM, Jonathon Mah wrote:
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:
40gmail.com
This email sent to 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