Question: Porting from Cocos2d-iPhone and memory management


#1

Greetings all,

I am considering taking the plunge and porting an app from cocos2d-iPhone to Cocos2d-X.

The thing is that I have never bothered to convert my app to use Automatic Reference counting (ARC)…becuase it is quite large and the retain/release/autorelease code appears to be working very well with no memory leaks. However, as we all know retain/releases code can be time consuming to code even when done right (and debugging can be a bear when simple mistakes are made).

In anycase, I had been considering moving to ARC for “simplicity of code” reasons but I was wondering if it is easier to port non-ARC code to Cocos2d-X since it appears that Cocos2d-X currently uses similar retain/release concepts?

I should mention that I did read the discussion about 3.0 changing to either Smart Pointers or Shared Pointers (instead of Retain/Release) but it seems that discussion (at least the thread I was reading) has not had a post in about 4 months… so I am unsure what the Cocos2d-X roadmap is at this point.

Anyway, my question is: Is it advantageous to convert to Cocos2d-X with non-ARC code or is it a better idea to simply convert my iOS app to ARC (putting of the port to Cocos2d-X for now) and wait for the new Cocos2d-X memory management to come online? (I am not in a real hurry to do either one, but I am trying to form a plan).

Any insight/recommendations would be appreciated.

Cheers,
Q


#2

Bump…

Bueller? Bueller? Fry? Fry?

Seriously, could anyone tell me if leaving non-arc (ie:retains/releases) will make porting to Cocos2d-X any easier, or is the whole retain/release paradigm being replaced by something that would make objective-c ARC (automatic reference counting) code easier to port?


#3

If you want the easiest conversion, then converting to ARC is the better choice. Cocos2d-x is for deploying your app on multiple platforms. If you want to run your app on Android, Windows Phone, PC, Mac, Linux, etc, then you would convert to Cocos2d-x. It will be more work though as Cocos2d-x is C++ and then new 3.0 release has changed a bit, while Cocos2d is Objective-C.


#4

@Questor wrote:

Bump…

Bueller? Bueller? Fry? Fry?

Seriously, could anyone tell me if leaving non-arc (ie:retains/releases) will make porting to Cocos2d-X any easier, or is the whole retain/release paradigm being replaced by something that would make objective-c ARC (automatic reference counting) code easier to port?

yeah, i am wondering about the memory management road map myself-- i don’t know if the cocos dev team has said anything on this matter recently. currently, though, cocos2d-x 3.0rc2 still uses the retain/release/autorelease paradigm, so at the moment, it may be easier to port non-ARC-enabled objective-C code. that’s just my 2 cents :slight_smile:


#5

Thanks guys…

@Javy Yeah I am already on Cocos2d-iPhone (objective-c) and I realize that that would mean going to full C++ (but some of my code is already C++ anyway as I am using/interfacing with Box2d as well). The question I was trying to decide was if not going to ARC first would make for an easier port since Cocos2d-X is using non-ARC paradigm as well.

@bunnyhero Yeah, that was originally what I was thinking (ie: that it may be easier to port the code without going to ARC first since the retain/release/autorelease code is already there.

I was just hoping that someone from the Cocos2d-X Dev team would chime in with an update/status of what the memory management roadmap looks like (and perhaps some guesstimate as to timeline).

I’d hate to have not done the ARC conversion only to find that a new Cocos2d-X paradigm is going to be used that is more like ARC (smartpointers, sharedpointers, etc) as it would be far easier for me to convert the App to ARC first due to my familiarity with Apple’s SDK… but again it only makes sense to move to ARC if Cocos2d-X is in fact going to move away from retain/release/autorelease to something that more closely resembles ARC.