• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa-dev Digest, Vol 6, Issue 742
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa-dev Digest, Vol 6, Issue 742


  • Subject: Re: Cocoa-dev Digest, Vol 6, Issue 742
  • From: Tron Thomas <email@hidden>
  • Date: Fri, 15 May 2009 22:30:17 -0700


On Fri, May 15, 2009 at 11:00 PM, Tron Thomas <email@hidden> wrote:
> Greg Parker wrote:
>>
>> On May 14, 2009, at 9:58 PM, Tron Thomas wrote:
>>>
>>> That did the trick. Â The stack trace allowed me to track down the cause
>>> of the error. Â Because Objective-C++ does not have a concept of class static
>>> variables I had an NSArray defined in an anonymous namespace in the
>>> implementation module that was initializing its contents. Â I changed the
>>> code so the array is initially set to nil in the anonymous namespace, and
>>> then assign it to an NSArray instance the init method of the class using the
>>> array if the array had not been initialize.
>>
>> I'm guessing the code you just wrote is not thread-safe - if two threads
>> are simultaneously the first to call -init then things might go wrong. If
>> you need thread-safe initialization, the +initialize or +load methods are
>> usually better.
>>
>>
> I looked into trying to use +initialize or +load to set the values of the
> array, as I thought it might be a better approach than using the -init
> function.
>
> When I used +load, I get the same problem I had before the array is getting
> setting before the main function executes and creates an auto-release pool.
>
> When I use +initialize the program crashes when it tries to access the array
> later on in the program life cycle. Â It seems like the array becomes
> corrupt. Â For some reason the debugger thinks it is an NSCFNumber instance
> instead of an array.
>
> What might be going wrong that is preventing +initialize from successfully
> creating the array?

Post your code.

I could guess at what's going on, but what's the point? If you post
your code, then certainty is likely to occur.

Any time you (or anyone else) starts *describing* what your code does,
stop, open your editor, select the code in question, and copy/paste it
into your e-mail. It's easier for you, and it's easier for everyone
else.

Mike
I fixed the problem. It turns out I was forgetting to retain the array. I'm not sure why it worked before when I was just creating it in the anonymous name space and the -init function.

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Cocoa-dev Digest, Vol 6, Issue 742
      • From: Michael Ash <email@hidden>
  • Prev by Date: Re: Using an arraycontroller for different object classes
  • Next by Date: Re: -[NSScriptCommand suspendExecution]
  • Previous by thread: Re: Does -copyPath:toPath:handler run synchronously?
  • Next by thread: Re: Cocoa-dev Digest, Vol 6, Issue 742
  • Index(es):
    • Date
    • Thread