• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: static objects "autoreleased with no pool in place - just leaking"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

References: 
 >static objects "autoreleased with no pool in place - just leaking" (From: m <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: j o a r <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: m <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: j o a r <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: m <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: j o a r <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: m <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: j o a r <email@hidden>)
 >Re: static objects "autoreleased with no pool in place - just leaking" (From: m <email@hidden>)

  • Prev by Date: Re: DictionaryWithContentsOfURL
  • Next by Date: Re: How to set up manual bindings
  • Previous by thread: Re: static objects "autoreleased with no pool in place - just leaking"
  • Next by thread: Re: static objects "autoreleased with no pool in place - just leaking"
  • Index(es):
    • Date
    • Thread