On 7 Jun 2013, at 07:29, Maxthon Chan wrote:
> Just asking, with ARC, is this a good choice on implementing singleton?
No, it's not thread-safe.
> //Singleton.h
> #import
> @interface Singleton : NSObject
> + (instancetype)defaultSingleton;
> // …
> @end
> extern Singleton *DefaultSingleton //
On 7 Jun 2013, at 09:26, "David Chisnall" 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 when a subclass is
u
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
+ (instancetype)share
On 7 Jun 2013, at 09:30, "Graham Lee" 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... maybe. Typicall
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] in
On 7 Jun 2013, at 09:34, Maxthon Chan 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 versions of
On 7 Jun 2013, at 09:42, Maxthon Chan 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 method asking
By the way, since you brought it up, in case Info.plist is not viable, can I do
this: (This is an CGI script in Objective-C and CGIApplication is analogue to
NSApplication)
// CGIApplication.h (This header is valid in both C and Objective-C.)
#ifndef CGIAPPLICATION_H
#define CGIAPPLICATION_H
#in
On 7. 6. 2013., at 10:47, David Chisnall wrote:
> On 7 Jun 2013, at 09:42, Maxthon Chan 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 s
Hi,
for toll-free bridging in CoreBase, I need a way to detect whether the
incoming pointer is a small object encoded in a pointer and act
accordingly (treat it as an ObjC object and avoid reading it).
What is the correct approach?
Thanks!
--
Luboš Doležel
_
The CF_IS_OBJC() macro will correctly identify small objects. The function
objc_getClass() will return a valid ObjC class that isn't toll-free bridged
and so CF_IS_OBJC() should return true. This should work.
On Fri, Jun 7, 2013 at 10:29 AM, Luboš Doležel wrote:
> Hi,
>
> for toll-free bridgi
I see. The problem is in CFGetTypeID() where the pointer is accessed in an
unsafe way (as you noted yourself in the code). I haven't given in much
thought yet, though...
Lubos
Dne 7. června 2013 17:41:15 Stefan Bidi napsal:
The CF_IS_OBJC() macro will correctly identify small objects. The
Ah, I see how this can be a problem. In this case, if I remember
correctly, small objects have the least significant bit set to 1. Checking
for that bit should be sufficient:
if ((0x01 & cf)) return _kCFRuntimeNotATypeID;
On Fri, Jun 7, 2013 at 11:02 AM, Luboš Doležel wrote:
> I see. The pr
On 7 Jun 2013, at 16:29, Luboš Doležel wrote:
> for toll-free bridging in CoreBase, I need a way to detect whether the
> incoming pointer is a small object encoded in a pointer and act accordingly
> (treat it as an ObjC object and avoid reading it).
In objc/runtime.h, there is a constant SMALL
On 7 Jun 2013, at 21:10, David Chisnall wrote:
> On 64-bit platforms, the low 3 bits will always be zero
P.S. I've done some profiling and discovered that in typical desktop
applications 5-20% of objects are small strings (up to 8 7-bit ASCII chars
stored in a pointer). This makes a fairly si
15 matches
Mail list logo
