Re: ARC and Singletons
Re: ARC and Singletons
- Subject: Re: ARC and Singletons
- From: Jeff Kelley <email@hidden>
- Date: Mon, 01 Aug 2011 14:39:41 -0400
Traditionally, I used the standard +sharedInstance type of singleton, but I returned it autoreleased and in its dealloc method, set the sharedInstance variable to nil if it was the shared instance:
> - (void)dealloc
> {
> if (self == sharedInstance) {
> sharedInstance = nil;
> }
>
> // Clean up ivars here
>
> [super dealloc];
> }
When I create a singleton I did it like this:
> + (MySingletonClass *)sharedInstance
> {
> if (sharedInstance == nil) {
> sharedInstance = [[[self alloc] init] autorelease];
> }
>
> return sharedInstance;
> }
That had the advantage of allowing the singleton to be released and free up its memory if no longer needed, but I think the tradeoff in code simplicity with ARC will be worth the handful of pointers that will stick around in memory with my singleton staying alive. There were also obviously concurrency concerns.
If I were retaining something large, such as graphics, in the singleton, I guess I’d have to respond to memory warnings appropriately and kill resources at that time.
Thanks for the feedback, guys.
Jeff Kelley
On Aug 1, 2011, at 1:52 PM, David Duncan wrote:
> On Aug 1, 2011, at 10:12 AM, Kyle Sluder wrote:
>
>> On Mon, Aug 1, 2011 at 9:05 AM, Dave Zarzycki <email@hidden> wrote:
>>> The simplest and most ARC friendly way to implement the singleton pattern is to switch from instance methods to class methods – because the class itself is by definition a singleton. In other words:
>>
>> Eek, this might be conceptually simple but it's a ton of work and
>> giant step backwards in API design. Remember when -[NSFileManager
>> alloc] became useful in 10.5?
>
>
> There's nothing wrong with using the +sharedInstance approach either, just remove all the shenanigans that were defined to ensure that there was only one instance. In the majority of cases it was likely overkill and potentially masking memory management bugs.
> --
> David Duncan
_______________________________________________
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