Re: static objects "autoreleased with no pool in place - just leaking"
Re: static objects "autoreleased with no pool in place - just leaking"
- Subject: Re: static objects "autoreleased with no pool in place - just leaking"
- From: Stefan Pantke <email@hidden>
- Date: Fri, 13 Feb 2004 13:46:49 +0100
Murat,
static variables will be allocated before any
method calls or code will be performed.
Thus, your code may yield this error messages, since the
main pool may or may not already be allocated.
I suppose, the main thread's pool will be allocated on a call to
[NSApplicaton sharedApplication].
Thus, your code may fail.
Moreover, it's certainly better to encapsulate your variables
into classes to reduce their scope - and enhance maintainability.
Kind regards,
Stefan
Am 13.02.2004 um 13:05 schrieb m:
On Feb 13, 2004, at 12:45 AM, j o a r wrote:
This is the kind of thing that I did all the time in C++, it's hard
to believe that no one has figures out a clean way to do it in
Obj-C++.
Just because you *had* to do something "all the time" in C++ doesn't
mean that you *need* to do it in Cocoa/ObjC, nor necessarily that you
should. When you learn something new, prepare to have to learn new
things.
Global variables might be "handy", but are frowned upon for several
reasons. Cocoa and Objective-C are used for OOP primarily.
Thanks for the wise words of advice. C++ is OOP too you know. And
they're not global variables, more like constants with global scope
that happen to be objects.
I certainly accept that Obj-C has its own idioms, but I don't accept
(yet) that this particular problem doesn't have a clean solution.
Maybe you just aren't aware of one... I'll post one if I come up with
one.
In an OO context you would not have things like this dangling around,
but would instead associate them with a class.
Now riddle me this: why are there examples of this kind of thing in
Cocoa itself? For example, there are a slew of NSString objects that
are available, or "dangling around". Notifications are one example
(NSWindowDidBecomeKeyNotification, etc).
In the meantime, your suggestion (which I've moved to for now)
requires moving from the conveniently concise and compact:
static NSColor* kColor1 = [NSColor colorWithDeviceRed: 0.6
green:0.6 blue:0.6 alpha:1.0];
static NSColor* kColor2 = [NSColor colorWithDeviceRed: 0.6
green:0.6 blue:0.4 alpha:1.0];
static NSColor* kColor3 = [NSColor colorWithDeviceRed: 0.3
green:0.6 blue:0.6 alpha:1.0];
static NSColor* kColor4 = [NSColor colorWithDeviceRed: 0.2
green:0.6 blue:0.8 alpha:1.0];
[...]
static NSColor* kColorN = [NSColor colorWithDeviceRed: 0.5
green:0.6 blue:0.6 alpha:1.0];
to the annoyingly verbose, distributed, and easier to screw up/harder
to maintain:
@interface NSColor(MyColorAdditions)
+ (NSColor*) color1;
+ (NSColor*) color2;
+ (NSColor*) color3;
+ (NSColor*) color4;
[...]
+ (NSColor*) colorN;
@end
@implementation NSColor(MYColorAdditions)
static NSColor* sColor1;
static NSColor* sColor2;
static NSColor* sColor3;
static NSColor* sColor4;
[...]
static NSColor* sColorN;
+ (NSColor*) color1
{
if (!sColor1)
{
sColor1 = [[NSColor colorWithDeviceRed: 0.6 green:0.6
blue:0.6 alpha:1.0]retain];
}
return sColor1;
}
[...]
+ (NSColor*) colorN
{
if (!sColorN)
{
sColorN = [[NSColor colorWithDeviceRed: 0.5 green:0.6
blue:0.6 alpha:1.0]retain];
}
return sColorN;
}
(Note that most of the colors that you claim to need to add as static
variables can already be obtained via convenience methods from
NSColor.
[etc.]
Yeah, sorry about that. The code I sent out was written as an
illustration of the kind of thing I'd like to do, not my actual code.
Regards,
_murat
_______________________________________________
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.
_______________________________________________
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.