Hey everyone
i read some stuff about the new automatic reference count feature in IOS 5
i see the discourage the use of "autorelease" which i understand is used a lot through cocos2d
how will that effect IOS 5 porting ?
IOS 5 and automatic reference counting
(42 posts) (20 voices)-
@cybergreg - LOL :D too bad I can't edit my earlier post :P
Well, if I understand well - ARC is not required in any way, it is only recommended, Cocos2d doesn't have to follow it (at least not yet)
Still, the whole thing does bring a few questions to the table:
1) Is ARC just a compiler setting and once compiled the code will run on any iOS, or does running a game compiled for ARC require an ARC-supporting OS ? It wasn't clear to me, someone please clarify it...
2) What should happen with Cocos2d-iPhone ? Riq has stated multiple times that he wants Cocos2d-iPhone to remain iOS/OSX API, thus it 'should' be converted to support ARC...
3) With Apple making such significant changes to the programming model - maybe it would be better to think again about moving to C++, where Apple can't do such things at all ?
4) Since in ARC C structs can't refer to Obj-C pointers - will the awesome cCCArray become obsolete ?
---
I always hated the whole release/retain/autorelease/assign/properties/synthesize stuff, but just like many others, I got used to it and... Now it's gone... ?
Posted 10 months ago # -
1) Is ARC just a compiler setting and once compiled the code will run on any iOS, or does running a game compiled for ARC require an ARC-supporting OS ? It wasn't clear to me, someone please clarify it...
It will analyze and optimize your code. Before linking. You can think of a second developer who adds all the retains and releases by analyzing how your code works. You send him your code and he sends your code to the linker.
As far as I understood it...
2) What should happen with Cocos2d-iPhone ? Riq has stated multiple times that he wants Cocos2d-iPhone to remain iOS/OSX API, thus it 'should' be converted to support ARC...
I am sure that ARC won't kill Cocos2D - it's just a compiler flag, keep cool. ^^
ARC is 100% part of the Objective-C collection (you can also see some speeches about this at the WWDC 2011 archive page). I think there needs to be an ARC and non ARC version of cocos2d. Unfortunately there is no
#ifdef ARC_IS_TURNED_ON
flag, I suppose.3) With Apple making such significant changes to the programming model - maybe it would be better to think again about moving to C++, where Apple can't do such things at all ?
Why? It's a good thing that Apple makes work easier for us. Also you have to use Objective-C to access core functions. Only some functions can be ported to native ANSI-C/C++.
Posted 10 months ago # -
@Paul - thanks ;)
1) That sounds much, much better then I originally thought. If that's how it's gonna be then it's really cool actually
2) In no way I was suggesting that this will in any way harm Cocos2d, no no ;) I only meant that since Cocos2d tries to follow the new features of iOS/Obj-C closely (e.g. - block support), then I understand that same thing should happen with ARC. Meaning - there's quite a lot of rewriting required. Not that it's a bad thing that would harm Cocos, but that quite a lot of work will be required to support it
3) I'm biased towards C++ and no change to ease the development in Obj-C will change that ;) I actually like quite a lot of things about Obj-C and don't mind working in it, but C++ will always feel superior for me
---
Still - what about 4) ? Shall Cocos2d support ARC (and I imagine that it will), what will happen with various C structs that are part of it ?
Posted 10 months ago # -
I was never a C++ coder, so it all looks like gibberish to me. :)
Now that we're at cocos2D 1.0, it might be a good time for someone to fork it and create an ARC-safe version. I really think the official base should NOT be built for ARC, since that will further splinter the cocos devs and make the forums scroll even faster with "I am following a 2 year old tutorial, and it breaks because of this ARC thing. Please rewrite my code." If we look to the future, do we really want to have ARC and non-ARC versions of 1.0 AND 2.0? Talk about chaos!
Posted 10 months ago # -
I read a blog about including cocos2d (perhaps as a prebuilt library, can't recall), however the gist of it was you can choose which files you want to use ARC on. So you can use ARC in your project even while a library / other files do not use ARC.
However I would think there is a greater benefit from using ARC completely, not just in bits and pieces.
If I can find the blog I will update / add to the thread.
Posted 10 months ago # -
@cybergreg - I don't see how that would work, if you even use a single CCNode in your class (and you probably will) - this CCNode has autorelease property set upon creation...
@Dragyn - yeah, I was thinking about that too. The feature might be useful, but with Cocos2d @ 1.0 this would be hellova switch for devs to adapt to. So maybe this should be part of Cocos2d 2.0 ? Or maybe a forked version ? But having separate forks and supporting both of them would be a mess...
Posted 10 months ago # -
Huh?
Am I late to the party here. I thought if you roll your own retained and release arc would just collapse them as part of its' analysis?
E.g.
Cocos2d adds some retains and arc also adds them at compile time, but then before final compile cancels out any superfluous retains/ releases.From what I gather arc and none arc code can be mixed freely but there are one or two struct specific caveats that can cause compile errors sna d cocs2d has these.
The point is that we can fix the compilation of cocos2d for arc (someone has already dome this in github) and still maintain none-arc manual reference counting.
I would love to see an arc flag compile firneldy version of cocos2d. Imagine how much better it would be to not get another bad access bug nor waste time with stupid memory leaks.
I don't see why fixing cocos2d arc compilation isn't being seen as a priority for the community. I'd chip in if i could but I'm fairly new to objective c
Wy arent more people drooling about this. Arc is the f@@ing bomb!!
Source : http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/10
Posted 10 months ago # -
Link to blog I previously mentioned: http://www.tinytimgames.com/2011/07/22/cocos2d-and-arc/
(with links to github as @infrid mentions above)I admit I spent about 30 minutes working on converting an existing project and my first stumbling block was I had to set the distribution version to 5, but we are supposed to be able to use ARC as far back as iOS4. I'm sure it's some project setting I missed.
Posted 10 months ago # -
There is an issue started already ;)
http://code.google.com/p/cocos2d-iphone/issues/detail?id=1199
Posted 10 months ago # -
@wilczarz:
My thoughts are (I think I mentioned them in a previous post):
-> ARC seems to be a nice feature, but it is not a MUST feature for cocos2d. cocos2d already handles the memory, so the users of cocos2d won't benefit from it.
-> It seems that it is possible to have files that are ARC and non-ARC
-> ARC is still in NDA, so I won't merge / implement ARC until the NDA is lifted
-> ARC is not backward compatible with iOS 3
-> So, I don't know if I will ever merge ARC in cocos2d 1.x
-> Probably I will merge ARC in 2.x, once the NDA is lifted, and once the 2.x code is stable. 2.x has too many features right now. And a new feature as big as ARC might introduce some noise.Posted 10 months ago # -
I agree with riq; ARC is not necessary. cocos2d takes care of most of the memory management issues for you. In a nutshell, ARC is a feature designed to reduce the burden of memory management from the programmer and offload it to the compiler. A side effect is that because the compiler has greater knowledge of all your code, it can optimize out calls to retain/release/autorelease if possible, potentially speeding up execution. TouchJSON saw a huge increase in performance just migrating to ARC.
Autorelease pools are fine in ARC, in fact Apple have introduced a new keyword @autoreleasepool specifically to manage an autorelease pool. It's also far more efficient that you manually managing it.
ARC itself is not under NDA, and fully documented on the llvm.org site, here. Additionally, the ARC migrator, used in Xcode 4.2 is open source and available in the current llvm SVN source.
Posted 10 months ago # -
ARC itself is not under NDA, and fully documented on the llvm.org site, here. Additionally, the ARC migrator, used in Xcode 4.2 is open source and available in the current llvm SVN source.
good to know.
Posted 10 months ago # -
@cybergreg: You can set the "deployment target" as far back as iOS 4, but your "base SDK" must be iOS 5.
Riq is right. Cocos2D itself doesn't need to be converted to ARC because it already handles it's own memory management. The purpose of the blog post was to allow *you* to write *your* code in ARC. As long as you include Cocos2D into your project as a cross-project reference or static library that was not built with ARC-compilation, you should be able to use Cocos2D as-is in your ARC project.
Posted 10 months ago # -
@jerrodputman - thanks, I knew that :-)
Try doing that with an ARC enabled project and let me know if it compiles ;-)
Posted 9 months ago # -
@jerrodputman: I have not read your blog yet, but thanks for the clarification.
Posted 9 months ago # -
-
Just as a dissident voice here, I'm in no rush to go to ARC. If you really understand the Objective-C memory management rules, there's no need for it, and for me it feels sloppy. I really don't want the compiler guessing what I meant to do and accommodating what I may or may not have intended behind my back. Plus, all the old code I have uses retain, etc. and all the examples available do, so this is really only useful for pure from-scratch projects. If you have any code in your project that doesn't use ARC, you better understand memory management. On top of that, you're still going to need to manage C++ object and malloc-type allocations, so it's better understand things anyway.
I'm just not a big fan of dumbing-down development so people don't need to learn basic concepts they should know. The fact is, you should be totally on top of your app's memory management and running your code through the instruments to see what it's doing. Otherwise you're just going to write crashing memory-hording code.
Posted 9 months ago # -
You shouldn't have memory leaks or unreleased memory unless you're writing incorrect or untested code. It really is not that hard to write correct code or to debug it if you're writing it well. It seems like most people don't bother to take the time to understand what they should be doing with memory management, and it really is not that hard.
Seeing ARC as a solution for writing crashing or leaky code is "dumbing-down" the development. People will write code that holds on to way too much memory (like expanded images at several meg a pop) because of it. That's going to be a "mysterious" problem for performance even if your app doesn't crash. Plus, you'll still see excessive memory-use alerts and app quits if you're doing things like that, so it's not like you don't need to debug memory issues anyway.
If you fully understand how to write good code that doesn't leak or waste memory and you want to use ARC, fine, but for people who don't know what they're doing, their code is still going to be a mess.
Posted 9 months ago #
Reply »
You must log in to post.