gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sync.m


From: icicle
Subject: Re: sync.m
Date: Sun, 28 Feb 2010 11:27:38 +0100
User-agent: Internet Messaging Program (IMP) H3 (4.0.4)

Hi!

After porting David's fixes from libobjc2 to the Objective2 framework @synchronized(class) works fine. Thank you all for your quick responses.

TOM



Zitat von Richard Frith-Macdonald <address@hidden>:


On 28 Feb 2010, at 08:42, address@hidden wrote:


Although this works, it is a really, really bad way of creating a singleton.

I copied it from the apple developer pages...

:-)

I thought +initialize would be called on program startup for every
class.

I guess you are confusing +initialize with +load

The +load method is called when your code is loaded into the program (usually on program startup unless your code is in a dynamically loaded bundle) The +initialize method is called the first time anything tries to *use* the class.

I want to be able to create my singleton on demand since it has
a rather large memory footprint. If that works with the method you
propose I'm fine with it.

+initialize is perfect for that.


Your +allocWithZone: method should really check that it's not a
subclass, before returning the singleton.

I don't want this class to be subclassed.

All the more reason why you should check.
eg.
+ (id) allocWithZone: (NSZone*)z
{
 if (self != [MyClass class])
   {
     []NSException raise: NSInvalidArgumentException
                              format: @"Illegal attempt to subclass MyClass as 
%@", self];
   }
 if (sharedInstance == nil)
   {
     sharedInstance = [super allocWithZone: z];
   }
}

In -initWithName:, you should check that self != nil after [super
init].  See the SUPERINIT macro from EtoileFoundation.

In a singleton, it's a good idea to override -dealloc to not call
[super dealloc].  This will cause a warning with GCC, which you can
hide like this:

- (void)dealloc
{
        if (0)
        {
                [super dealloc];
        }
}

How would you deallocate your singleton then?

Typically you don't deallocate singletons ... the idea is that they are created on demand and then are available for the rest of the program. If you *want* to manually destroy the singleton before the program ends, you can just add an extra class method to set sharedInstance to nil and release the object, then -dealloc could do this:

- (void) dealloc
{
 if (self != sharedInstance)
   {
     [super dealloc];
   }
}

If you want multiple instances of the class, but never more than one at a time, then you wouldn't create them in +initialize (and this wouldn't really be what is meant by 'singleton'). In that case you would use a lock to protect critical bits of code, have +allocWithZone: return the existing instance (if there is one), and have -dealloc reset the sharedInstance variable to nil.





_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev








reply via email to

[Prev in Thread] Current Thread [Next in Thread]