Re: Newbie question: instantiate a class in its header file OR in IB
Re: Newbie question: instantiate a class in its header file OR in IB
- Subject: Re: Newbie question: instantiate a class in its header file OR in IB
- From: Andrew Farmer <email@hidden>
- Date: Tue, 24 Jun 2008 22:28:23 -0700
On 24 Jun 08, at 20:34, JArod Wen wrote:
I am a cocoa newbie from Java. Recently I found an example code in
which the instance of a class is defined in its own class's header
file, as following:
@interface AppController : NSObject {
// Instance variables here
}
AppController *appController;
This example code is incorrect. Importing this header file from more
than one source file will result in multiple definitions of
appController - the only reason it's working in the example project is
probably because there's only one .m file which imports this header.
Remember that the text of the file being #included or #imported is
simply inserted into the file which includes it - there's no
distinction between source created through inclusion and source
present in the original file. Hence, there's no distinction between a
variable which is multiply defined by a bad header and a variable
which is multiply defined by mistake.
Adding the "extern" qualifier to the definition in the header will
cause the symbol to be treated as a reference to a single variable,
which you'll have to explicitly define elsewhere.
The correct approach, however, is simply to not make that variable
public at all. Assuming that this is to implement a singleton pattern,
standard practice is to create a class method which'll return a shared
instance - compare +[NSWorkspace sharedWorkspace], among many other
methods in AppKit which use this pattern.
I am a little bit confused by this code. Since always we will create
the controller in IB and then I think the instance will be created
by IB, right? So is there any advanced features/reasons for this
kind of usage?
Nope. All this does is define a variable - it doesn't allocate an
instance. That'd have to happen in +initialize or something.
_______________________________________________
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