On May 31, 2012, at 8:59 PM, Antonio Nunes wrote:
> Couldn't we just [[NSObject alloc] init]? I think @synchronized cares about
> pointer uniqueness, not about the class, no? (And, as I learned from this,
> under ARC the pointer should also actually respond to memory management
> methods, i.e.
On May 31, 2012, at 10:59 PM, Antonio Nunes wrote:
> On 1 Jun 2012, at 02:34, Charles Srstka wrote:
>
>> static dispatch_once_t onceToken;
>> dispatch_once(&onceToken, ^{
>> myVLFContext = [[VLFContext alloc] init];
>> });
>>
>> @synchronized(myVLFContext) {
>> ...
>> }
>
> That does
On 1 Jun 2012, at 02:34, Charles Srstka wrote:
> static dispatch_once_t onceToken;
> dispatch_once(&onceToken, ^{
> myVLFContext = [[VLFContext alloc] init];
> });
>
> @synchronized(myVLFContext) {
> ...
> }
That does seem better. Any reason though to create a custom class? Couldn't
On May 31, 2012, at 3:28 PM, Lane Roathe wrote:
> Suggestions:
>
> 1. remove the k prefix, by convention that is reserved for constants
>
> 2. don't use the same var name for a local variable as for a global variable
>
> 3. That should be something like:
>
> static VLFContext* myVLFContext = n
Le 31 mai 2012 à 22:28, Lane Roathe a écrit :
>
> On May 31, 2012, at 2:00 PM, Jean-Daniel Dupas wrote:
>
>> Le 31 mai 2012 à 18:00, Jens Alfke a écrit :
>>
>>> On May 31, 2012, at 8:47 AM, Antonio Nunes wrote:
>>>
static void *kMyVLFContext = &kMyVLFContext;
>>> ...
@synchroni
On May 31, 2012, at 2:00 PM, Jean-Daniel Dupas wrote:
> Le 31 mai 2012 à 18:00, Jens Alfke a écrit :
>
>> On May 31, 2012, at 8:47 AM, Antonio Nunes wrote:
>>
>>> static void *kMyVLFContext = &kMyVLFContext;
>> ...
>>> @synchronized(kMyVLFContext) {
>>
>> Huh? I thought the parameter to
Le 31 mai 2012 à 18:00, Jens Alfke a écrit :
>
> On May 31, 2012, at 8:47 AM, Antonio Nunes wrote:
>
>> static void *kMyVLFContext = &kMyVLFContext;
> ...
>> @synchronized(kMyVLFContext) {
>
> Huh? I thought the parameter to @synchronized(…) had to be an object
> reference?
The Obj
On 31 May 2012, at 17:00, Jens Alfke wrote:
> Huh? I thought the parameter to @synchronized(…) had to be an object
> reference?
Well, yes, but my understanding was/is that it was essentially about the
pointer, and this formula worked just fine until I migrated to ARC. I think
Scott is right th
On 31 May 2012, at 17:14, Scott A Andrew wrote:
> My guess is that you are crashing because kMyVLFContext is not an objective C
> object. According to the Apple documentation
> (https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocThreading.html#//apple_
On May 31, 2012, at 8:47 AM, Antonio Nunes wrote:
> static void *kMyVLFContext = &kMyVLFContext;
...
> @synchronized(kMyVLFContext) {
Huh? I thought the parameter to @synchronized(…) had to be an object reference?
—Jens
___
Cocoa-dev maili
It looks a bit suspicious to me that you're instantiating the dictionary in
your hidden "… work ..." code, then using it in the visible code, but not
releasing it.
Is it possible that the dictionary started out as an ObjC object that you don't
own, and you used a (__bridge CFDictionaryRef) cast
My guess is that you are crashing because kMyVLFContext is not an objective C
object. According to the Apple documentation
(https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocThreading.html#//apple_ref/doc/uid/TP30001163-CH19-SW1):
The @synchronized() d
I have a function that looks essentially like this:
static void *kMyVLFContext = &kMyVLFContext;
Boolean myFunction(CFURLRef path)
{
CFDictionaryRef myDictionary = NULL;
@synchronized(kMyVLFContext) {
… work …
}
return myDictionary != NULL
13 matches
Mail list logo
