Re: class variables
Re: class variables
- Subject: Re: class variables
- From: Ofri Wolfus <email@hidden>
- Date: Tue, 20 Feb 2007 19:59:54 +0200
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