Re: Is there a bug in #include operation?
Re: Is there a bug in #include operation?
- Subject: Re: Is there a bug in #include operation?
- From: Sherm Pendley <email@hidden>
- Date: Mon, 1 Mar 2004 16:15:53 -0500
On Mar 1, 2004, at 3:33 PM, Denis Stanton wrote:
Is there a problem in Xcode 1.1's handling of #include where classes
are mutually dependent ?
There are many ways to work around circular dependencies like you're
describing.
The best way is to avoid them to begin with. Most .h files don't
actually need to import other .h files - for argument and return types,
you don't need the whole class definition, so declaring the classes
with @class is generally good enough. You can import the whole header
file in the .m file, where knowing the exact methods an object responds
to is actually important.
For protocols, put them in .h files by themselves, and declare
arguments and return types that use them as id<ProtocolName> - that is,
an object that conforms to the given protocol.
Minimizing the cross-includes and circular dependencies will also speed
up your build times, by minimizing the number of .m files that have to
be rebuilt each time a header is changed.
A class does need to include its superclass' header, though.
For that, the easiest thing to do is simply use #import instead of
#include - it's an Objective-C improvement over #include that
essentially says "include this if it hasn't been included already."
Alternatively, you can do what C programmers have been doing since
nearly day zero, and wrapping your headers in guardian #ifdef
directives. For example, in foo.h, you'd do something like this:
#ifndef __FOO_H__
#define __FOO_H__
... interesting stuff goes here...
#endif
sherm--
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.