Re: sync.m
On 1 Mar 2010, at 00:12, Riccardo Mottola wrote: > It is not that I removed and changed stuff randomly, I just changed it where > I needed it to get things to compile. Yes, I think we all understand that. > So I'd like the compatibility library to continue to compile. I'm perfectly > fine to use the old libobjc on the systems with old or weird compilers. Using the old libobjc is not currently a problem, the problem is using the old API (or more accurately, having to use multiple runtime APIs)... I'm not really happy to continue using the old API for two reasons: To keep the code maintainable, we want to use a single API rather than using #ifdef to select alternative code fragments for different APIs. To maximise portability between GNUstep/OSX, we need that single API to be the one Apple use (we've tried using our own, and people weren't happy with that choice). The compatibility code should let us use the single API we want, with both old and new runtimes, so I'm very grateful that Etoile provided it. > As long of course as core itself doesn't require libobjc-2 feature (which I > hope will be never, but that's tough to say). That depends what you mean by 'require' ... some of Apples new OSX APIs cannot be implemented without ObjC2 features because they are built in to the API ... so to implement those features we will *have* to use ObjC2. However, for the forseeable future we are going to want to have GNUstep be able to build without ObjC2 on platforms where it is not available (and just leave the bits which require Objc2 unimplemented in those cases). > Things used to work well enough even on gcc 2.95 to have the whole gnustep > core, gworkspace, systemprefrences, projectcenter, gorm and all of GAP > compiling and working. That is all I ask, I do not expect to use Obj-c2 > programs or etoile there. But breaking them gratuitously is stupid. Nobody is breaking things gratuitously. The c99isms slip in to code simply because all modern compilers support them, and don't warn you that older compilers won't. Most people use them habitually (locality of declaration of variables is particularly good for code readability for instance) and simply won't notice that they have used them. Asking people to upgrade and use more modern compilers won't break any existing applications (old code will continue to compile), but would mean that we wouldn't have to keep trying to remember not to use c99 features, we wouldn't need to waste the time of people like you and me 'fixing' code which slips through into svn using them, and arguably we could write slightly better code. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
Hi, Actually, David's original comment is a bit wide of the mark anyway ... changes to the ObjectiveC2 code are rather more than just reindentation as it needed a bug fix or two and quite a few changes to fix c99isms which prevented it building on older systems (and the whole point of a compatibility library is to allow older systems, specifically older versions of the runtime, to work without having to have masses of #ifdef's in the code). If we want to keep ObjectiveC2 and libobc2 sufficiently in sync to allow patches from one to be applied to the other, we will need to restructure quite a bit of the libobjc2 code to avoid c99 features where possible, and David put a comment to Riccardo in libobjc2 specifically asking him not to do that (since the new library will only work on more modern systems), so unless David wants to reconsider, such synchronisation is impossible anyway :-( It is not that I removed and changed stuff randomly, I just changed it where I needed it to get things to compile. So I'd like the compatibility library to continue to compile. I'm perfectly fine to use the old libobjc on the systems with old or weird compilers. As long of course as core itself doesn't require libobjc-2 feature (which I hope will be never, but that's tough to say). Things used to work well enough even on gcc 2.95 to have the whole gnustep core, gworkspace, systemprefrences, projectcenter, gorm and all of GAP compiling and working. That is all I ask, I do not expect to use Obj-c2 programs or etoile there. But breaking them gratuitously is stupid. Up to know I was able to detect and patch the stuff, it wasn't that hard, I just need sometimes help from the original author to understand what the code actually does. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
It's my own application which shows this behaviour. I do not have a theme enabled, I am using the cairo backend. Everything is built from current svn trunk. Gorm shows the same broken behaviour on my machine, screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0. Thanks TOM Zitat von Fred Kiefer : I just tried to reproduce this behaviour and failed to. On which application are you seeing this and probably more important, which GNUstep backend are you using? Do you have a theme enable? Am 27.02.2010 18:54, schrieb ici...@mail.cg.tuwien.ac.at: Looks like NSTabView in trunk is currently buggy. I attached a screenshot to this message. Gorm from svn trunk displays it the same way. Tell me if you need further information. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev <>___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
I just tried to reproduce this behaviour and failed to. On which application are you seeing this and probably more important, which GNUstep backend are you using? Do you have a theme enable? Am 27.02.2010 18:54, schrieb ici...@mail.cg.tuwien.ac.at: > Looks like NSTabView in trunk is currently buggy. I attached a > screenshot to this message. Gorm from svn trunk displays it the same > way. Tell me if you need further information. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
On 28 Feb 2010, at 17:22, Gregory Casamento wrote: > My apologies... I misunderstood the difficulty here. I'd forgotten > that there is ObjectiveC2 and libobjc2. :) > > I'm not certain what the right solution here is beyond continuing to > backport as best we can to ObjectiveC2. I don't think it's a big deal ... this is fairly simple stuff. The complex/clever part of libobjc2 that David is working on, is the stuff which isn't in the ObjectiveC2backward compatibility code anyway. Basically we have two scenarios ... 1. modern systems using libobjc2 (fully featured ObjC2 code) 2. older systems (including most current production system) which won't ever get full featured ObjC2 support. The compatibility library means we can use the same runtime API for both scenarios, but it's not going to give the older systems the full ObjC2 feature set... some of the functions in the API will be no-ops > However, I think the question I asked in the previous email I sent is > still relavent in general, though not related to this problem. Yep .. I'd kind of like to say we can forget non-c99 systems. I know that Riccardo uses some. I know that Dr Nikolaus Schaller uses old compilers on his embedded systems But ... I'm not sure that the old compilers are *required*, it's probably a hassle to get a newer toolchain working on these old systems, but maybe not a bad thing to upgrade. At FOSDEM Felipe told me that the older compilers actually produce smaller code! So that might be an issue for embedded systems. However, I've also heard that Clang produces smaller code than current GCC (no idea if that's true), so it might pay for people currently using old compilers to look into updating to either the latest gcc or to Clang. So ... while I wouldn't take it upon myself to unilaterally insist on c99 compiler support yet, I would be strongly in favour of at least putting it on a roadmap and requiring the people using those old compilers either commit to a timetable for updating, or provide a convincing argument why we shouldn't. PS. after a recent linux specific bugfix, it looks like clang from svn trunk is finally able to build a working version of gnustep-base on gnu/linux (well, passing all the expected regression tests and working for a few apps I tested) using David's libobjc2 and the non-fragile-ivar ABI. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
My apologies... I misunderstood the difficulty here. I'd forgotten that there is ObjectiveC2 and libobjc2. :) I'm not certain what the right solution here is beyond continuing to backport as best we can to ObjectiveC2. However, I think the question I asked in the previous email I sent is still relavent in general, though not related to this problem. GC On Sun, Feb 28, 2010 at 11:44 AM, Richard Frith-Macdonald wrote: > > On 28 Feb 2010, at 15:06, Gregory Casamento wrote: > >> Just one thing here... if conforming to the coding standards is going >> to be a point of contention, then I don't think we need to be very >> strict on them, at least not until after the code is completed and >> stabilized. >> >> GC >> >> On Sun, Feb 28, 2010 at 4:36 AM, Richard Frith-Macdonald >> wrote: >>> >>> On 27 Feb 2010, at 18:39, David Chisnall wrote: >>> I've now fixed this case in libobjc2. Unfortunately, someone decided to 'helpfully' reindent the version of ObjectiveC2.framework in GNUstep, which means that diffs from libobjc2 no longer cleanly apply in ObjectiveC2 (nor to diffs against the original version in Étoilé svn), so whoever did that gets to volunteer to back-port the changes. >>> >>> Guess we should think about getting libobjc2 to conform to the coding >>> standards soon. At least that's easier because it's largely C code rather >>> than ObjC, and the 'indent' program will largely do it for us. > > Well, that's why I didn't mention it until now (hopefully the code is getting > stable ... it mostly seems to work). It makes me wonder though, if it would > be worth the effort of making the indent program work for objective-c (I've > always liked the idea of just automatically converting things to a common > style with indent when a file is committed but people being able to > regenerate their preferred style with indent on checkout ... it really should > be possible). > > Actually, David's original comment is a bit wide of the mark anyway ... > changes to the ObjectiveC2 code are rather more than just reindentation as it > needed a bug fix or two and quite a few changes to fix c99isms which > prevented it building on older systems (and the whole point of a > compatibility library is to allow older systems, specifically older versions > of the runtime, to work without having to have masses of #ifdef's in the > code). > > If we want to keep ObjectiveC2 and libobc2 sufficiently in sync to allow > patches from one to be applied to the other, we will need to restructure > quite a bit of the libobjc2 code to avoid c99 features where possible, and > David put a comment to Riccardo in libobjc2 specifically asking him not to do > that (since the new library will only work on more modern systems), so unless > David wants to reconsider, such synchronisation is impossible anyway :-( > > > > > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
I think one thing we seriously need to examine is how critical support for compilers which do not support C99 really is. Do any of the embedded platforms require gcc 2.95.x? GC On Sun, Feb 28, 2010 at 11:44 AM, Richard Frith-Macdonald wrote: > > On 28 Feb 2010, at 15:06, Gregory Casamento wrote: > >> Just one thing here... if conforming to the coding standards is going >> to be a point of contention, then I don't think we need to be very >> strict on them, at least not until after the code is completed and >> stabilized. >> >> GC >> >> On Sun, Feb 28, 2010 at 4:36 AM, Richard Frith-Macdonald >> wrote: >>> >>> On 27 Feb 2010, at 18:39, David Chisnall wrote: >>> I've now fixed this case in libobjc2. Unfortunately, someone decided to 'helpfully' reindent the version of ObjectiveC2.framework in GNUstep, which means that diffs from libobjc2 no longer cleanly apply in ObjectiveC2 (nor to diffs against the original version in Étoilé svn), so whoever did that gets to volunteer to back-port the changes. >>> >>> Guess we should think about getting libobjc2 to conform to the coding >>> standards soon. At least that's easier because it's largely C code rather >>> than ObjC, and the 'indent' program will largely do it for us. > > Well, that's why I didn't mention it until now (hopefully the code is getting > stable ... it mostly seems to work). It makes me wonder though, if it would > be worth the effort of making the indent program work for objective-c (I've > always liked the idea of just automatically converting things to a common > style with indent when a file is committed but people being able to > regenerate their preferred style with indent on checkout ... it really should > be possible). > > Actually, David's original comment is a bit wide of the mark anyway ... > changes to the ObjectiveC2 code are rather more than just reindentation as it > needed a bug fix or two and quite a few changes to fix c99isms which > prevented it building on older systems (and the whole point of a > compatibility library is to allow older systems, specifically older versions > of the runtime, to work without having to have masses of #ifdef's in the > code). > > If we want to keep ObjectiveC2 and libobc2 sufficiently in sync to allow > patches from one to be applied to the other, we will need to restructure > quite a bit of the libobjc2 code to avoid c99 features where possible, and > David put a comment to Riccardo in libobjc2 specifically asking him not to do > that (since the new library will only work on more modern systems), so unless > David wants to reconsider, such synchronisation is impossible anyway :-( > > > > > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
On 28 Feb 2010, at 15:06, Gregory Casamento wrote: > Just one thing here... if conforming to the coding standards is going > to be a point of contention, then I don't think we need to be very > strict on them, at least not until after the code is completed and > stabilized. > > GC > > On Sun, Feb 28, 2010 at 4:36 AM, Richard Frith-Macdonald > wrote: >> >> On 27 Feb 2010, at 18:39, David Chisnall wrote: >> >>> I've now fixed this case in libobjc2. Unfortunately, someone decided to >>> 'helpfully' reindent the version of ObjectiveC2.framework in GNUstep, which >>> means that diffs from libobjc2 no longer cleanly apply in ObjectiveC2 (nor >>> to diffs against the original version in Étoilé svn), so whoever did that >>> gets to volunteer to back-port the changes. >> >> Guess we should think about getting libobjc2 to conform to the coding >> standards soon. At least that's easier because it's largely C code rather >> than ObjC, and the 'indent' program will largely do it for us. Well, that's why I didn't mention it until now (hopefully the code is getting stable ... it mostly seems to work). It makes me wonder though, if it would be worth the effort of making the indent program work for objective-c (I've always liked the idea of just automatically converting things to a common style with indent when a file is committed but people being able to regenerate their preferred style with indent on checkout ... it really should be possible). Actually, David's original comment is a bit wide of the mark anyway ... changes to the ObjectiveC2 code are rather more than just reindentation as it needed a bug fix or two and quite a few changes to fix c99isms which prevented it building on older systems (and the whole point of a compatibility library is to allow older systems, specifically older versions of the runtime, to work without having to have masses of #ifdef's in the code). If we want to keep ObjectiveC2 and libobc2 sufficiently in sync to allow patches from one to be applied to the other, we will need to restructure quite a bit of the libobjc2 code to avoid c99 features where possible, and David put a comment to Riccardo in libobjc2 specifically asking him not to do that (since the new library will only work on more modern systems), so unless David wants to reconsider, such synchronisation is impossible anyway :-( ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
Just one thing here... if conforming to the coding standards is going to be a point of contention, then I don't think we need to be very strict on them, at least not until after the code is completed and stabilized. GC On Sun, Feb 28, 2010 at 4:36 AM, Richard Frith-Macdonald wrote: > > On 27 Feb 2010, at 18:39, David Chisnall wrote: > >> I've now fixed this case in libobjc2. Unfortunately, someone decided to >> 'helpfully' reindent the version of ObjectiveC2.framework in GNUstep, which >> means that diffs from libobjc2 no longer cleanly apply in ObjectiveC2 (nor >> to diffs against the original version in Étoilé svn), so whoever did that >> gets to volunteer to back-port the changes. > > Guess we should think about getting libobjc2 to conform to the coding > standards soon. At least that's easier because it's largely C code rather > than ObjC, and the 'indent' program will largely do it for us. > > ___ > Discuss-gnustep mailing list > discuss-gnus...@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnustep > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
On 28 Feb 2010, at 08:42, ici...@mail.cg.tuwien.ac.at wrote:
>> Although this works, it is a really, really bad way of creating a singleton.
>
> I copied it from the apple developer pages...
This is rarely a good idea, unfortunately. Apple's API documentation is very
good, but their example code doesn't seem to have been written by programmers
so it often does things in ways that are more appropriate to thedailywtf.com
than developer.apple.com.
> I thought +initialize would be called on program startup for every
> 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.
There are two methods on a class that will be called by the runtime; +load and
+initialize. The +load method is called as soon as the class is loaded. At
this point, you can guarantee that the class and its superclasses are loaded,
but you can't guarantee anything else about the state of the system.
Generally speaking, any code using +load is wrong. I think I've used it twice,
and both times it's been for something quite ugly.
The +initialize method is much safer. It is called, in a thread-safe way, by
the runtime when the first message is sent to the class. The first message
sent to a class is usually something like +alloc, +new, or +sharedInstance.
Creating the singleton in +initialize will create it in the right place.
I was going to suggest that you look in Erik Buck's Cocoa Design Patterns, but
it turns out that he also does it wrong - his non-thread-safe solution is more
complex and slower than the thread-safe one, which is a shame; I'd have
expected better from an old NeXT programmer.
>> 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.
As Richard said, the best solution in this case is to throw an exception if the
+allocWithZone: method is called on a subclass. This will prevent any
subclasses from working.
> How would you deallocate your singleton then?
That's a good question. The answer in your current code is 'prematurely'. You
are not retaining your singleton when it is returned, so either calling code
will treat it like a singleton and never -release it, or it will -release it
causing it to be destroyed and your global to be a dangling pointer.
Erik suggests implementing a +attemptDealloc method that calls -release if
-retainCount returns 1, but that's a messy and silly idea.
If you want to be able to deallocate and recreate the singleton, be aware that
you need to set the static pointer to nil. You also need to rewrite your
+sharedInstance method like this (where instanceLock is an NSLock created in
+initialize and sharedInstance is the instance pointer, both are file statics):
+ (id)sharedInstance
{
id obj;
[instanceLock lock];
obj = sharedInstance;
if (nil == obj)
{
obj = sharedInstance = [self new];
}
obj = [obj retain]
[instanceLock unlock];
return [obj autorelease];
}
Your dealloc method will then look like this:
- (void)dealloc
{
[instanceLock lock];
if ([self retainCount] == 0)
{
sharedInstance = nil;
// do cleanup
[super dealloc];
}
[instanceLock unlock];
}
It's important that you check the retain count before freeing the singleton,
because otherwise you might have one thread call -sharedInstance while another
calls -release. The +sharedInstance method will acquire the lock, blocking the
-dealloc method in the other thread. When the -dealloc method is entered, you
have to check that you really should proceed with the deallocation. Don't
actually destroy the object unless no other thread has gained a reference to
it.
In general, as Richard says, you don't deallocate singletons. They are
expected to exist for the lifetime of the program. The lazy-initialization
trick just means that they don't really exist until observed; you can still
reason about them as if they did exist from the program start (unless creation
of them has side effects).
>> By the way, where did you get the spaces-inside-square-brackets style
>> from? I don't think I've ever seen Objective-C written like that.
>
> I didn't get it anywhere, that's my own :)
Interesting. What's the rationale for it? It looks a bit more Smalltalk-like.
I can imagine it working quite nicely in an editor that does rainbow brackets.
David
-- Sent from my STANTEC-ZEBRA
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
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 :
On 28 Feb 2010, at 08:42, ici...@mail.cg.tuwien.ac.at 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
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
On 27 Feb 2010, at 18:39, David Chisnall wrote: > I've now fixed this case in libobjc2. Unfortunately, someone decided to > 'helpfully' reindent the version of ObjectiveC2.framework in GNUstep, which > means that diffs from libobjc2 no longer cleanly apply in ObjectiveC2 (nor to > diffs against the original version in Étoilé svn), so whoever did that gets > to volunteer to back-port the changes. Guess we should think about getting libobjc2 to conform to the coding standards soon. At least that's easier because it's largely C code rather than ObjC, and the 'indent' program will largely do it for us. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
On 28 Feb 2010, at 08:42, ici...@mail.cg.tuwien.ac.at 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
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
Although this works, it is a really, really bad way of creating a singleton.
I copied it from the apple developer pages...
I strongly suggest that you create it in +initialize instead.
If you really must use @synchronized(), you should put a test
outside, like this:
if (nil == sharedInstance)
{
@synchronized(self)
{
if (nil == NP_ENGINE_CORE)
{
NP_ENGINE_CORE = [self new];
}
}
return NP_ENGINE_CORE;
}
At least this way you will only have to do the (very expensive)
objc_sync_enter/exit thing once, or maybe twice. If you implement it
with +initialize, however, you don't have to do it at all:
+ (void)initialize
{
if ([NPEngineCore class] == self)
{
NP_ENGINE_CORE = [self new];
}
}
+ (id)sharedInstance
{
return NP_ENGINE_CORE;
}
The runtime will handle the locking for you, calling the +initialize
method precisely once, the first time the class is sent any message.
You can then guarantee that the singleton instance already exists by
the time the +sharedInstance method is called. You could also then
eliminate the need for @sycnhronized() in +allocWithZone: because if
NP_ENGINE_CORE is still nil then you are being called from the
+initialize method.
I thought +initialize would be called on program startup for every
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.
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.
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?
By the way, where did you get the spaces-inside-square-brackets style
from? I don't think I've ever seen Objective-C written like that.
I didn't get it anywhere, that's my own :)
Thanks
TOM
David
On 27 Feb 2010, at 22:47, ici...@mail.cg.tuwien.ac.at wrote:
Hi!
I put together a testcase, this used to work before the switch
ObjectiveC2 framework. Lin 62 is the one causing the crash.
Thanks
TOM
Zitat von ici...@mail.cg.tuwien.ac.at:
Hi!
looks like it is not fixed :( Richard ported the code over to the
ObjectiveC2 framework immediately, but it still does not work. Now I
get "Uncaught exception NSInvalidArgumentException, reason:
(null)(class) does not recognize instance". As "instance" is the
class method which creates the singleton now something else seems to
go wrong.
Thanks
TOM
Zitat von David Chisnall :
I've now fixed this case in libobjc2. Unfortunately, someone
decided to 'helpfully' reindent the version of ObjectiveC2.framework
in GNUstep, which means that diffs from libobjc2 no longer cleanly
apply in ObjectiveC2 (nor to diffs against the original version in
Étoilé svn), so whoever did that gets to volunteer to back-port the
changes.
On 27 Feb 2010, at 17:40, Richard Frith-Macdonald wrote:
You are probably in a better position than anyone else to be aware
of precisely what parts of ObjectiveC-2 are most efficient or
inefficient, and how they compare to the traditional ways of doing
things. Have you considered producing a paper describing those
differences? If we had them quantified we would have a really good
guide for people to know when to use new features and when to avoid
them (and when it really doesn't matter).
Well, I did write a book that describes them...
@synchronized is basically impossible to implement efficiently.
It's a stupid feature added to make life easier for Java programmers
who are too lazy to think when they learn a new language. There are
basically three ways you can do it:
1) Allocate a pthread_mutex_t with every object
Pros: Fast, simple
Cons: Wastes at least one word of memory for every object, including
the 99.9% that are never used as arguments to @synchronized().
2) Have a shadow data structure mapping objects to locks.
Pros: Doesn't waste much memory.
Cons: Extra locking on the shadow structure needed, extra code
needed to remove locks when they are no longer needed, overhead
performing the lookup.
3) Add a hidden class between the object and its real class which
stores the lock.
Pros: Relatively simple and non-invasive.
Cons: Needs an extra class structure for every locked object.
libobjc2 / ObjectiveC2.framework use option 3. We use
objc_allocateClassPair(), which doesn't work for creating just a new
metaclass (although we fail slightly more gracefully than Apple's
version, which just returns a pointer to a random address). I've
now added a s
