Just asking, with ARC, is this a good choice on implementing singleton?
//Singleton.h
#import Foundation/Foundation.h
@interface Singleton : NSObject
+ (instancetype)defaultSingleton;
// …
@end
extern Singleton *DefaultSingleton // Of course this is optional
// Singleton.m
Singleton
On 7 Jun 2013, at 07:29, Maxthon Chan xcvi...@me.com wrote:
Just asking, with ARC, is this a good choice on implementing singleton?
No, it's not thread-safe.
//Singleton.h
#import Foundation/Foundation.h
@interface Singleton : NSObject
+ (instancetype)defaultSingleton;
// …
@end
extern
On 7 Jun 2013, at 09:26, David Chisnall david.chisn...@cl.cam.ac.uk wrote:
My preferred pattern is:
+ (void)initialize
{
[[self alloc] init];
}
Should this be wrapped in if(self == [Singleton class])? I've seen that used to
guard against this +initialize being called multiple times
I don't want an exclusive singleton - that is, there is not only one shared
singleton instance, the user can also set up one for their own, like recent
versions of NSFileManager on OS X.
Can I do this:
// Singleton.m
static Singleton *__singleton
@implementation Singleton
+
On 7 Jun 2013, at 09:30, Graham Lee gra...@iamleeg.com wrote:
Should this be wrapped in if(self == [Singleton class])? I've seen that used
to guard against this +initialize being called multiple times when a subclass
is used that doesn't override the method.
Good catch. The answer is...
Well can I (just like NSApplication):
1) In supercalss, define the shared instance as id
2) In superclass, return the shared instance as id or instancetype
3) In superclass, DO NOT set up yet.
4) In superclass, set up in the method asking for the shared instance, which
always use [[self alloc]
On 7 Jun 2013, at 09:34, Maxthon Chan xcvi...@me.com wrote:
I don't want an exclusive singleton - that is, there is not only one shared
singleton instance
Exclusive singleton is a tautology. By definition, singletons are exclusive.
, the user can also set up one for their own, like recent
On 7 Jun 2013, at 09:42, Maxthon Chan xcvi...@me.com wrote:
Well can I (just like NSApplication):
1) In supercalss, define the shared instance as id
2) In superclass, return the shared instance as id or instancetype
3) In superclass, DO NOT set up yet.
4) In superclass, set up in the
On 7. 6. 2013., at 10:47, David Chisnall thera...@sucs.org wrote:
On 7 Jun 2013, at 09:42, Maxthon Chan xcvi...@me.com wrote:
Well can I (just like NSApplication):
1) In supercalss, define the shared instance as id
2) In superclass, return the shared instance as id or instancetype
3) In
It depends on how the object is used -- in this case (without looking at
the code), it sounds like it's a typical singleton approach.
On Wed, Jun 5, 2013 at 8:07 AM, Germán Arias ger...@xelalug.org wrote:
Thanks for the explanation. I knew about static variables with strings
(like @hello).
Thanks for the explanation. I knew about static variables with strings (like
@hello).
And that these don't should be released. But I did not know that this applies to
other objects.
Thanks.
Germán.
On 2013-06-04 23:55:15 -0600 Graham Lee gra...@iamleeg.com wrote:
That's returning a shared
NSComboBoxCell doesn't release its popup window, but it doesn't retain it
either so there's no unbalanced memory use.
Graham.
On 4 Jun 2013, at 00:33, Germán Arias ger...@xelalug.org wrote:
For autocomplete I have a class GSAutocompleteWIndow. The
method -complete: (in NSTextVIew) do
On 2013-06-03 23:59:15 -0600 Graham Lee gra...@iamleeg.com wrote:
NSComboBoxCell doesn't release its popup window, but it doesn't retain it
either so there's no unbalanced memory use.
Graham.
Well, isn't retained. But is created with +alloc and -init. And since
this is a panel, this
Where are you seeing that? I'm looking at -_popUp here:
http://svn.gna.org/svn/gnustep/libs/gui/trunk/Source/NSComboBoxCell.m
No -init, -new or -copy that I can see.
Graham.
On 5 Jun 2013, at 00:30, Germán Arias ger...@xelalug.org wrote:
On 2013-06-03 23:59:15 -0600 Graham Lee
Class method +defaultPopUp, line 118.
Germán.
On 2013-06-04 23:38:10 -0600 Graham Lee gra...@iamleeg.com wrote:
Where are you seeing that? I'm looking at -_popUp here:
http://svn.gna.org/svn/gnustep/libs/gui/trunk/Source/NSComboBoxCell.m
No -init, -new or -copy that I can see.
Graham.
That's returning a shared static instance of the GSComboWindow class, so it's
expected that it isn't released. It's also outside of the NSComboBoxCell class,
so as far as NSComboBoxCell instances are concerned, they should obey standard
memory management rules:
- if you got an object via
For autocomplete I have a class GSAutocompleteWIndow. The
method -complete: (in NSTextVIew) do something like:
GSAutocompleteWindow *window = [GSAutocompleteWindow defaultWindow];
[window displayForTextView: self];
I think I should release this window at some point. Maybe in
-dealloc or with a
Can you compile it with -fobjc-arc and check again? Probably with ARC you can
have some ideas.
在 2013-6-4，上午7:33，Germán Arias ger...@xelalug.org 写道：
For autocomplete I have a class GSAutocompleteWIndow. The
method -complete: (in NSTextVIew) do something like:
GSAutocompleteWindow *window =
On 4. 6. 2013., at 02:14, Maxthon Chan xcvi...@me.com wrote:
Can you compile it with -fobjc-arc and check again? Probably with ARC you can
have some ideas.
When you're not sure how something is memory managed, compiling with ARC is
probably a terrible idea.
Turning magic into
A side note about autocomplete, I always cross-develop GNUstep apps under OS X,
just for that Xcode capabilities. I really should build a GNUstep/Linux
toolchain and SDK for Xcode to use so that at least before ProjectCenter and
Gorm is in good shape we can develop using Xcode on OS X and copy
On 2013-06-03 18:58:39 -0600 Ivan Vučica ivuc...@gmail.com wrote:
The method is named +defaultWindow; it does not include alloc, create,
new; hence its retaincount is +1 (-1), which is how I denote currently
1, but autoreleased once.
This method includes +alloc and -init. But what confuses
21 matches
Mail list logo
