At one stage, using retain generated an error at compile time. The advice was clearly to use assign (or copy). But the latest I can find is a message from one of the runtime engineers: “(retain) and (assign) are identical under GC.”
But dealloc has never been supported under GC.
You don’t use alloc unless the method that follows starts with init. dictionaryWithContentsOfFile: has the alloc built in.
You should use self.theDictionary although I don’t think what you did should give you a bad access error. Did you try logging filePath to see if it’s giving you a good path?
Ric
Hi Ric,
The file path (and the file itself) are correct.
if I
NSLog(@"Dic %@ ", self.theDictionary);
I get
2012-05-08 02:14:06.271 testObjC[26709:403] Dic Dic
(lldb)
then bang.
Bernard,
I can’t see what’s wrong with what you have – you have my email, why don’t you send me a copy of your testObjC project, and I’ll have a look at it.
Ric
Ok, I got from Ric a working solution. In fact, one should know what are ASOC properties equivalents in ObjC. The docs are unclear on this matter, because scripters just have to declare:
In Objective-C this should be:
No need to deallocate “by hand”.
We had always this problem with the old Memory Manager of the Toolbox, we prevented “handles” (pointers to pointers) to move by freezing them into memory to dereference them safely, and we had to unlock them and free them “manually”. As I read, the Garbage Collector is reliable, and to send messages to nil objects does not make you restart your Mac anymore. --remember the “bomb” icon? 
Happy coding!
Bernard,
See my post above – assign and retain are identical under garbage collection – they both do an assign (you can’t do a retain in GC).
The problem is using an autorelease object without using an local autorelease pool. The error can happen anywhere on the fly because the object is added to a pool in another scope. As soon as the ‘unknown’ pool receives a drain the dictionary is freed. So use alloc->init or new methods just like most of Apple’s example code and use retain->release or turn garbage collector on when you start with Objective-C. It makes the start a bit easier
Well, I don’t want to play on thin ice. What is best?
Compiler LLVM GCC 4.2 with Garbage Collection “supported/required”
or
Compiler LLVM compiler 3.1 with Garbage Collection “unsupported” ?
I hope you’re not trying to share your Objective-C knowledge already with us when you just start. Like Shane mentioned the properties behaves differently with GC on or off. please don’t share bad/incomplete information. Assign, copy and retain are used in different situations. Otherwise Apple wouldn’t give us a choice, you’re not in the ASOC world anymore. Sometimes I want to use assign while the next time I want to use copy or retain. With autorelease I can use a retain without any problem but when no autorelease is used and GC is turned off I know there is a high change of multi retains and will cause leaks. In those cases I use copy, assign or write the get and set myself.
As far for a compiler. In basic terms it only adds some support for changes to a programming language and most of the changes are compiler instructions so I would go for GCC 4.2 (i use it myself). GC is just some machine code that is added to your compiled code. It also runs in 1 - 4 threads next with your code (that’s why you application loses 10% performance in general).
If you are keeping any ASObjC code, in practice you need to use garbage collection. That may change in future; it’s been publicly stated that garbage collection will be deprecated in 10.8.
The whole issue of memory management is a thorny one. Long-time Objective-C programmers are comfortable with retain/release, and many don’t see the need to change. Garbage collection looks doomed (sadly, IMO). ARC (automated reference counting) looks like the way of the future, and arguments about factory methods versus init/new will largely become moot.
For someone starting out like you at the moment, that’s not much comfort…
The supported/required distinction is really for frameworks that will be used in other projects.
I don’t think the compiler will make any difference for you, although the LLVM compiler looks to be the way of the future.
Thanks to remind me that, I almost forgot. 
By the way, I didn’t find this myself, I just trying to understand how all this work.
So I’ll use this compiler (it’s not the default one) with garbage collection required. I get one warning:
cc1obj: warning: -Wuninitialized is not supported without -O
which gets away if I change the optimization level (for debug). Is that ok?
No, you’re right, I’m not smart enough to see the differences (and probably I’ll never be), but if I don’t set all options accordingly, the project won’t build. and that makes a difference.
The project that Bernard sent to me was using ARC, not GC, and the use of assign for the NSMutableDictionary was what was causing his app to crash. Since he mentioned that he was interested in iOS as well as OS X, I think that ARC is the way to go – it certainly seems like the way Apple is pointing us. It is my understanding that ARC takes care of pretty much all the memory management as long as you stick to cocoa ( but core foundation objects are a different matter). If this isn’t true, I hope someone will enlighten me.
As far as retain, assign or copy, it seems like (from what I’ve seen) that as a general rule of thumb, you want to use retain for objects other than strings, where you use copy, and assign for IBOutlets and primitive types. I know this isn’t always true, but for someone starting out in Objective-C, it’s a place to start. I don’t even know whether we should still be using retain and assign, it looks like Apple is moving to strong and weak.
Ric
It takes care of most of the mundane stuff, but you still effectively have responsibility with things like properties.
You’re right.
Properties in projects/files with arc should be defined the same way as other non GC projects. Performance-wise ARC doesn’t drop performance like GC but arc is more statically while GC is more dynamic. GC had a big advantage with objects that are created at run time like ASOC. The big difference is that ARC is a pre compiler while GC works at runtime. The only thing I don’t like about ARC is that it behaves like a zombie (read:stupid). I mean It adds release and retains for you, it could also look if the coder has added a retain or release already but it doesn’t. Another dislike is that I’m not allowed to create C structure anymore with pointers to Objective-C objects. For tool free bridge types (you named core foundation objects) needs a special casting. ARC indeed only applies for objects that have an retain counter (Objective-C objects). In other words for lightweight high level applications arc can be useful but a lot of developers needs to work with core foundation types (which are faster).
However I like the @autorelease{…} because it makes your code better readable, increase performance and best of all you don’t need to have ARC enabled to use this. But I name this because it is introduced with ARC.
Thank you for all these informations!
. So, I’d like to have confirmation that I have understood the basics:
For ASOC projects, GC ON. No worries about Properties.
For ObjC projects, it remains unclear (sorry). There are a number of build options, certain seem to work, others produce run-time error, others produce fatal errors. These options, sometimes mutually exclusive, are:
a) the choice of the compiler
b) the CG options [unsupported/supported/required]
c) code optimization level
d) ARC
These settings, according to what I have read from you, seem to determinate how to set property attributes.
Now please, as a beginner in ObjC, I don’t want to generate debates on what is the best solution for a specialist working with C or core foundation, I would just ask for the best settings for:
considering:
Every hints are very, very welcome!
Regards,
Again I’d like to recommend to learn the language.
At least read Apple’s The Objective-C Programming Language
Look also into the programming guides for the basic Foundation classes (string, number, the collections, date, url)
Personally I read also these books, they were and still are very helpful:
Cocoa Programming for Mac OS X by Aaron Hillegass
Programming in Objective-C by Stephen Kochan.
Thank you Stefan
The Objective-C Programming Language is already in my iPad’s iBooks, I read it every night. but what I like is to read, test, read again, test again. I just wanted to get Xcode configured to play with these new notions.
For the moment I have the same tiny “application” (half a dozen of properties, four or five handlers and a basic interface with a window, some controls and table views). my more complex line is
classNames = [NSMutableArray arrayWithArray: [[theDictionary allKeys]sortedArrayUsingSelector:@selector(compare:)]];
So really the basics. May I go with the defaults settings?
Could anyone recommend an Objective-C book that is easy to understand in the same way Shane Stanley did with his great book. That’s of course provided that the individual has programing ability.
I like ASOC as it allows me to write simple apps that I can use at work. but if I can learn OC that will be a plus provided I have the time to dedicate to it.
I just had a look on Kochan’s book and its approach is non-C programming 
. I will personally follow Stefan’s hint and load these books on my iPad.