Re: class variables
Re: class variables
- Subject: Re: class variables
- From: Bob Smith <email@hidden>
- Date: Tue, 20 Feb 2007 15:18:15 -0800
Hmmm, not to question the docs or anything, but experience doesn't
agree. I had this issue in the front of my mind because I just got
bit by it last week, in a situation where I had a class
implementation which contained only class methods and static data,
and was never instantiated. I was tearing my hair for a few hours
before I finally threw an NSLog in +initialize and found it was never
being called. What the documentation says is true about +initialize
being called before the first method call to an _instance_ of a
class; but it's clear that +initialize is not guaranteed to have been
called before a _class_ method is called. It would appear that
+initialize is being called somewhere in the instance initializer
chain, i.e. in NSObject's -init.
Also if you read all the way through that documentation section, at
the end it warns that a class' +initialize can be called more than
once. If you have a superclass which implements +initialize and a
subclass of it which does not override, the superclass' +initialize
will be called both when the superclass is first instantiated, then
again the first time the subclass is instantiated. So if you are
using +initialize to allocate static data, you should guard against
allocating more than once (good practice in any case when allocating
static data).
Bob S.
On Feb 20, 2007, at 1:55 PM, Ofri Wolfus wrote:
+initialize is invoked by the runtime before the first message to
the class is dispatched and not before it is instantiated, so the
first example is fine although both ways are valid. See http://
developer.apple.com/documentation/Cocoa/Reference/Foundation/
Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/clm/
NSObject/initialize
The advantage of +initialize is that it is guaranteed to be invoked
exactly once so if your class should be thread safe, +initialize
may be easier to use.
- Ofri
- - - - - - - - - - - - - - - - - - -
http://www.dpompa.com
- - - - - - - - - - - - - - - - - - -
On 20/02/2007, at 23:45, Bob Smith wrote:
Remember that +initialize is not invoked until the first time a
class is instantiated; so the example will work only if the
methods are in a class that is always instantiated before you need
to access the array. If you need the data in instances of other
classes, or you want to have a separate class just for your static
data, it's safer to have the accessor create the array on demand:
@implementation DataClass
static NSArray *myArray = nil;
+ (NSArray *)myArray {
if (!myArray) {
myArray = [... retain];
}
return(myArray);
}
@end
Bob S.
On Feb 20, 2007, at 9:59 AM, Ofri Wolfus wrote:
I'd definitely go with (1) if your array doesn't take a lot of
memory. There's nothing wrong with keeping a small array you need
*all* the time (read as long as the app is running) and letting
the system clean up the memory on termination.
And if you want to wrap this array in a class method, i'd do
something like this (typed in Mail):
@implementation MyClass
static NSArray *myArray = nil;
+ (void)initialize {
myArray = [[NSArray arrayWithObjects:...] retain];
}
+ (NSArray *)myArray {
return myArray;
}
@end
This way your array will only be allocated before the first call
to a method of MyClass and be freed by the system when the
program terminates.
- Ofri
- - - - - - - - - - - - - - - - - - -
http://www.dpompa.com
- - - - - - - - - - - - - - - - - - -
On 19/02/2007, at 16:08, Jim Thomason wrote:
I've got a list of useful data I need to use stored in an NSArray.
Just a list of strings (class names) in a particular order, which I
need to use for sorting purposes. I originally just had my sort
method
constantly re-allocate and subsequently destroy this array
every...single...time. Not the right way to do it, but it's
conceptually easy. Now it's time to clean it up.
So...what would be the recommended way to do it? Standard notes
on the
web for things like singletons say to set it up as a static
variable,
and pay attention to the "application will terminate"
notification to
deallocate the variable. But, my situation is slightly different
since
it's not an instance of my class that I want static - it's an
NSArray.
I see several different approaches:
1) Just set it up statically and not worry about memory
management. I
only want one instance of it and it should persist through the
run of
the entire app anyway. I don't need to worry about catching the
terminate reply to release it, since it'll be cleaned up by program
end anyway.
2) Re-factor so that each of my classes has its own "rank"
method that
returns the value that's otherwise inferred from the NSArray. This
splits the info across multiple classes and makes it more
annoying to
manage going forward (needing to update multiple classes to
change the
ranks, fo rinstance, instead of being centralized).
3) Re-factor so my NSArray is wrappered in some singleton class,
and
go through the standard hoops of releasing at terminate.
4) Add on a category to NSArray to watch for the terminate note and
release it that way.
5) Just make my NSArray an object instance, take the hit of
allocating
a dozen or so copies of it, and not worry about the rest of the
details.
6) Something else I haven't thought of.
I like (1) because it's the simplest, but the fact that I never
release just gives me a mental block that I'm doing *something*
wrong.
(4) & (5) sound pretty easy. (2) & (3) sound like a mess and too
much
work.
So, world, what would you do?
-Jim......
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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)
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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)
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