but for people who don't know what they're doing, their code is still going to be a mess.
Well, that's kinda true for any language or compiler feature. ;^)
IOS 5 and automatic reference counting
(42 posts) (20 voices)-
@clarus: I agree completely. Isn't this the problem developers are having with the Android SDK? Memory leaks aren't too big a problem for PCs and consoles now which have enormous amounts of memory to work with but with smartphones you are still dealing with some devices which have only 16MB of shared memory.
I'm all for ease of development, which is why I'm using Objective-C as opposed to C++, but perhaps ARC is too soon?
Posted 9 months ago # -
Now that Xcode 4.2 has been officially released for a few weeks now, what is the status of this?
I recently made the changes to make Objective-Chipmunk ARC friendly (it was actually really trivial). I was curious how much work it would be to do the same for Cocos2D as I wanted to redo some of my example code to use ARC to show how much simpler it can make things.
90% of the work was in ccCArray.h and that really just boiled down to making some defines and sprinkling them in.
#if __has_feature(objc_arc) // I have no clue where the header that defines these is. id objc_retain(id); id objc_release(id); typedef __unsafe_unretained id CCARRAY_ID; #define CCARRAY_RETAIN(obj) objc_retain(obj) #define CCARRAY_RELEASE(obj) objc_release(obj) #else typedef id CCARRAY_ID; #define CCARRAY_RETAIN(obj) [obj retain] #define CCARRAY_RELEASE(obj) [obj release]; #endifNothing fancy and I believe nothing that will break compatibility with earlier versions of Xcode pre 4.2 or iOS 3. Should I make a patch for 1.x after testing to make sure everything works as expected?
Edit: Oh also, it will require changing the templates (or making a new one probably) so that they have a static library target for Cocos2D where ARC is disabled.
Posted 6 months ago # -
andrew
MemberWould objc_retain and objc_release be considered private APIs? They're defined here: http://www.opensource.apple.com/source/objc4/objc4-493.9/runtime/objc-internal.h and it says:
/* * WARNING DANGER HAZARD BEWARE EEK * * Everything in this file is for Apple Internal use only. * These will change in arbitrary OS updates and in unpredictable ways. * When your program breaks, you get to keep both pieces. */Posted 6 months ago # -
Yeah, I wasn't sure about them. The ARC docs for LLVM says that they are defined and those are the functions that the compiler emits instead of actual method calls, but I couldn't figure out where they were declared... I was a bit nervous about it before seeing the comment you found in their header. ;)
I actually figured out yesterday that the correct thing to do is to make the array be __strong id * as strong object references in C arrays are allowed, just not in C structs. That works as long as the array is allocated using calloc() instead of malloc() and as long as you nil out the references as they are removed from the array. So no need to use those functions then.
I tested the changes a bunch on one of my example projects yesterday and it appears to work just fine. I'll make a pull request for it later today if I have the time.
On the other hand, after playing with ARC a bunch, I'm not 100% convinced that it's actually any easier... It requires so much extra type annotation that it seems like it might not actually be easier. I guess it really comes down to whether or not it helps prevent making memory leaks in the long run as they tend to be such a time sink to fix when you forget a single release somewhere in the thousand lines of code that you just wrote. If it helps prevents those sorts of mistakes, then I'll be sold I guess.
Posted 6 months ago # -
Jerrodputman's fork has a coco2d ARC compatible version:
https://github.com/jerrodputman/cocos2d-iphone/commits/developI'll merge it both for cocos2d v1.x and 2.x
Posted 6 months ago # -
If you just make a typedef for the id array type you don't need to move all the ccArray functions into a c module and can leave them all be static inline. Although I suspect that the performance isn't going to matter that much. Dunno.
Posted 6 months ago # -
@slembcke: thanks. I have just seen your patch. I will merge it tomorrow.
https://github.com/cocos2d/cocos2d-iphone/pull/123Posted 6 months ago # -
Thanks. Merged patch both in v1.1 and v2.0 branches.
Posted 6 months ago # -
sundialsoftware
MemberI have written 2 apps, both on the app store, one with ARC & one without. ARC simply saves loads of time both in writing code and testing. Cocos2D can be set up to work with ARC (see http://www.tinytimgames.com/2011/07/22/cocos2d-and-arc/) and that's what I plan to test out shortly. Hopefully I can make similar changes to Cocos3D to have it working as well.
I don't see anything bad about ARC. It's much closer to the more modern approach taken by other systems, dare I mention Visual Studio.
Posted 6 months ago #
Reply
You must log in to post.