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:
+ (MyClass *)sharedInstance;
// and maybe override alloc/retain/release to enforc
e be mindful of the fact that ARC does not magically fix
concurrency issues (globals or otherwise).
davez
>
> Jeff Kelley
>
>
> On Mon, Aug 1, 2011 at 12:05 PM, Dave Zarzycki wrote:
> The simplest and most ARC friendly way to implement the singleton pattern is
> to
Karl,
This is not on our todo list or any list that I know of. Please file a bug
report if this enhancement request is interesting to you.
Thanks! :-)
davez
On Aug 2, 2011, at 4:59 PM, Karl Goiser wrote:
> Hi Greg,
>
> Is that wishful thinking or a hint about the future?
> :-)
>
>
> All I
Thomas,
Why not use a NSMutableSet and avoid the bridging casts entirely?
davez
On Aug 29, 2011, at 7:20 AM, Thomas Davie wrote:
> I'm not really very clear on how ARC and CF types are meant to interact yet,
> because of that I've managed to create some buggy code, could someone have a
> qu
Or, your code could subclass NSMutableSet and interpose the methods that add to
the set. In other words, mentally separate "objects that are equal" from
"objects that should be in the set". The former is an equality check, the
latter is a policy decision.
davez
On Aug 29, 2011, at 7:37 AM, Th
Andreas,
This is probably not the answer you're looking for, but when we find coding
patterns like this in the OS, we advice developers to replace this pattern with
a GCD queue and use either dispatch_sync() or dispatch_async(). The reason for
this advice is because parking threads to wait for
On Sep 14, 2011, at 9:38 AM, Andreas Grosam wrote:
>
> On Sep 14, 2011, at 4:20 PM, Dave Zarzycki wrote:
>
>> Andreas,
>>
>> This is probably not the answer you're looking for, but when we find coding
>> patterns like this in the OS, we advice developers
On Sep 14, 2011, at 12:08 PM, Andreas Grosam wrote:
>
> On Sep 14, 2011, at 8:00 PM, Dave Zarzycki wrote:
>
>> Dispatch queues exist to solve both the synchronous and asynchronous
>> producer/consumer pattern. If you want the producer to wait until the
>>
On Oct 14, 2011, at 11:44 PM, Jean-Daniel Dupas wrote:
>
> Le 15 oct. 2011 à 01:45, Quincey Morris a écrit :
>
>> On Oct 14, 2011, at 14:27 , Greg Parker wrote:
>>
>>> Do you actually use exceptions in your code, or do you follow the Cocoa
>>> convention that exceptions are for programmer erro
On Oct 15, 2011, at 12:10 PM, Seth Willits wrote:
> Unrelated, when did @autoreleasepool pop in? I don't remember if I knew about
> that or not. It's _used_ once in the Obj-C Programming Language guide, but
> never documented anywhere I can find.
@autoreleasepool {} is new with Xcode 4.2 and Ap
On Oct 30, 2011, at 10:32 AM, James Merkel wrote:
> The document on ARC talks about problematic C structs like:
>
> struct x { NSString *S; int X; } StaticArray[] = {
> @"foo", 42,
> @"bar, 97,
> ...
> };
>
> I use that pattern quite a bit in my code and haven't had any problems with
> it. T
You're tripping across a fundamental aspect of how virtual memory works. For
example: what do you expect will happen if you do this on an iOS device (none
of which have more than 512*1024*1024 bytes of memory)?
void *x = malloc(1024*1024*1024);
assert(x);
The answer depends on w
James,
We need a lot more information before we can give any help. Please strongly
consider reducing your experience down to a compilable test case.
Good luck,
davez
On Nov 17, 2011, at 1:49 PM, James Maxwell wrote:
> I have a method that's crashing with EXC_BAD_ACCESS. I'm running a fairly
Howard,
If you don't want to rename your .cpp file to .mm, then you can just tell Xcode
to ignore the file extension and always compile as Objective-C++. Then your C++
code can call Objective-C code natively when compiling for Mac OS X / iOS.
davez
On Jan 31, 2012, at 11:31 AM, Howard Moon
On Feb 11, 2012, at 9:49 PM, Kyle Sluder wrote:
> On Feb 11, 2012, at 3:56 PM, Charles Srstka wrote:
>
>> On Feb 11, 2012, at 5:25 PM, William Squires wrote:
>>
>>> is ARC a Lion-only feature or will an ARC-compiled app work on 10.6.8
>>> assuming no other Lion features are used?
>>
>> Every
On Feb 12, 2012, at 12:06 PM, Mike Abdullah wrote:
>
> On 12 Feb 2012, at 02:49, Kyle Sluder wrote:
>
>> On Feb 11, 2012, at 3:56 PM, Charles Srstka wrote:
>>
>>> On Feb 11, 2012, at 5:25 PM, William Squires wrote:
>>>
is ARC a Lion-only feature or will an ARC-compiled app work on 10.6
Koko,
Are you using C++? (Probably.) If you are, then do you have a "const" version
of Set? (Probably not.)
If the above is not true, then what is the exact compiler error, and can you
reduce this down to a test case?
Thanks!
davez
On Feb 15, 2012, at 3:14 PM, koko wrote:
> I need to know
On Mar 6, 2012, at 11:51 AM, Jan E. Schotsman wrote:
> Hello,
>
> I have an array of progress values (number objects) for subprojects, from
> which I calculate the overall progress .
> The array is an atomic property of the project class.
>
> Is it safe to access this array from multiple thr
We support "fat" binaries. Please use them to avoid this problem entirely. You
just need to reconfigure your kext project to build both architectures at the
same. A simple example from the command line:
/tmp $ cat test.c
#include
int
main(void)
{
printf("sizeof(void *) == %zu\n
Roland,
Check this out:
http://cocoawithlove.com/2008/03/cocoa-application-startup.html
The code should arguably live in a +initialize method.
davez
On Feb 24, 2011, at 6:41 AM, Roland King wrote:
> I burned myself today with a pattern I've been using for ages. I have lots of
> UIV
On Apr 14, 2011, at 6:20 AM, WT wrote:
> Hi all,
>
> I've started to use GCD in my projects and I found myself using a certain
> pattern that I now realize isn't actually thread safe. The goal is to write a
> thread-safe lazy accessor without using locks, @synchronized, or an atomic
> propert
On Apr 14, 2011, at 10:11 AM, WT wrote:
> Hi Dave,
>
> thanks for replying. I must say some of what you said went above my head. :)
>
> On Apr 14, 2011, at 2:02 PM, Dave Zarzycki wrote:
>
>>> The first is that if the method gets invoked already in the queue's
Here is a trick to help you better understand how to use autorelease pools
correctly. Put this in a header somewhere:
static inline void subpool(void (^block)(void))
{
NSAutoreleasePool *_pool = [[NSAutoreleasePool alloc] init];
block();
[pool drain];
}
… and use it like
On May 20, 2011, at 5:48 AM, Ben wrote:
> MyImportController *controller = nil;
> CleanupBlock cleanup = ^{
> [controller release];
> // Other stuff
> };
> controller = [[MyImportController alloc] initWithCleanupBlock:[[cleanup copy]
> autorelease]];
> [controller start];
> // The con
On May 30, 2011, at 1:45 PM, julius wrote:
>
> On 30 May 2011, at 20:03,Quincey Morris wrote
>>
>> On May 30, 2011, at 08:27, julius wrote:
>>
>>> All I had hoped was that someone on this list might illuminate the issue
>>> more than has happened so far.
>>
>> The problem isn't really lack of
Jonathon,
This is being tracked by our internal bug number 8590846. I'm told that the
workaround is to place the array within a structure:
__block struct {
double result[COUNT];
} results;
davez
On Dec 14, 2010, at 7:30 PM, Jonathon Kuo wrote:
> I'm trying to learn GCD and reading
Jonathon,
GCD is an object oriented API done in C. If you look at the man page entitled
dispatch_object, you'll see that one can call dispatch_set_context() and
dispatch_get_context() against any GCD object (sources and queues are where
they make the most sense). In fact, if you're simply looki
On Jan 6, 2011, at 12:17 PM, Jonathon Kuo wrote:
>
> On Jan 5, 2011, at 12:41 PM, Dave Keck wrote:
>
>>> Q: When a context object is set with dispatch_set_context(), is it
>>> retained? Or do I need to retain it first, set it, and then in the cancel
>>> handler release it?
>>
>> The 'context'
no will be equal to EPIPE.
davez
On Jan 6, 2011, at 1:22 PM, Jonathon Kuo wrote:
> On Jan 6, 2011, at 1:15 PM, Fritz Anderson wrote:
>
>> Taking "by value" to mean "as many uninterpreted bits as will fit into a
>> variable of type void*," yes.
>
> On J
On Jan 10, 2011, at 2:06 PM, Jonathon Kuo wrote:
> I set up a source handler on a TCP socket like this:
>dispatch_source_t newsrc =
> dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,sockfd,0,globalQueue);
>
> It works well, and when a client process closes his socket my cancel_handler
> g
On Jan 10, 2011, at 3:04 PM, Jonathon Kuo wrote:
>
> On Jan 10, 2011, at 2:58 PM, Ken Thomases wrote:
>
>> On Jan 10, 2011, at 4:20 PM, Dave Zarzycki wrote:
>>
>>> On Jan 10, 2011, at 2:06 PM, Jonathon Kuo wrote:
>>>
>>>>
Scott,
Please reduce this down to a test case so that we might try and reproduce what
you are observing.
Thanks!
davez
On Mar 24, 2012, at 1:17 AM, Scott Andrew wrote:
> I seem to have hit a few limitations with ARC.
>
> 1.) Subclasses of CALayer are not being fully released which causes m
Brad,
This looks similar to Radar 10434539. Let me know if this works: simplify the
header includes in your code to just #import and just link
against Quartz. If your code is already doing this, then let us know.
Thanks!
davez
On Mar 31, 2012, at 3:39 PM, Brad Stone wrote:
> I used "Edit
On Apr 15, 2012, at 3:46 PM, Markus Spoettl wrote:
> On 4/15/12 8:06 PM, Scott Ribe wrote:
>> On Apr 15, 2012, at 12:01 PM, Markus Spoettl wrote:
>>
>>> I have an NSDictionary that contains, well, objects. When I call
>>> -objectForKey: I get nil for keys that are definitely in there.
>>>
>>>
On Apr 16, 2012, at 8:10 PM, Graham Cox wrote:
> Memory management is really quite straightforward, and consists of a few
> rules that everything follows (the framework invariably does; your code
> should do).
If that were true, then ARC would not have been necessary.
> On 16/04/2012, at 7:4
On Apr 17, 2012, at 1:28 AM, Graham Cox wrote:
> …having been using Objective C productively for over 10 years now, that I
> still find ARC something I have not needed. So far. I'm kinda hoping that
> remains true, because it actually seems pretty complicated in order to cover
> all the arcane
On Apr 25, 2012, at 6:07 PM, Kévin Vavelin wrote:
> Hi there,
>
> I've a question about the dispatch_timer function. I try to make a strobe
> flash on my iPhone app and for that i used an NSTimer but a friend of mine
> say that it's better to use dispatch function. So i was looking and try to
Please reduce this down to a simple test case. Thanks!
On Jun 13, 2012, at 4:16 AM, Vojtěch Meluzín wrote:
> Hi,
>
> I'm trying to make x64 work on XCode 4 Mac OS 10.7, but whenever I use a
> system constant, such as kCFAllocatorDefault, I get this linker error (on x86
> it works fine):
>
>
38 matches
Mail list logo
