If you're using a synthesized retain @property, releasing in dealloc can be done:

[hud release], hud = nil; // assigning nil isn't required, but habit to ensure its nil

or

[self setHud:nil]; // I prefer this when using properties, the retain/release are synthesized in the getter/setter

With that said, if your hud layer has been added to the scene, you don't need to retain it. You can simply use (assign) instead of retain and not worry about the dealloc. The layer object will be retained when you call [self addChild:hud] or where ever you add the layer.

Generally retaining the object too long creates a memory leak, so I'm wondering if your crash is related to something else? Do you have more details on where your crash is happening?

Hi there, I have made a hud layer.
In my action layer I make reference to the hud layer...

HudLayer *hud;
}
@property (nonatomic, retain) HudLayer *hud;

Everything seems to work perfectly.

The problem is that when I look in dealloc of my actonLayer.mm it says "on "dealloc" you need to release all your retained objects" I then notice that I have retained hud.

I have tried adding self.hud = nil; and [hud release]; into the actionLayer dealloc.... but the app crashes with both of these.

I have added a checker of CCLOG(@"dealloc:%@", self); in my dealloc which does get called when I exit actionLayer.

Just wondered... do I need to release hud, or is there a way to not retain it??

sorry if the solution is obvious, I'm not too experienced with this.
thanks
moomy

okk Thanks.

cocos2d v2.0-beta && v1.1 is compatible with ARC(release notes). Not sure if any earlier versions are.

hi guys,
i am a freshman to memory too, i have searched the internet .and found ,the autorelease variable will release when the runloop() method ends. but when does the runloop() end? when need i use the runloop() method, i alomost know nothing..

I am using Xcode 4.2 and building a game for iphone (from iOS 3.0 - 5.0). Does cocos2d support ARC? What modifications needs to be made to convert code written in previous versions?

If I use the strong and weak keywords for variables and set compiler to LLVM GCC 4.2, what will be the results? Is it a necessity to change compiler to 3.0 to support ARC?

Can anyone point me in the right direction?

Thanks!

The best advice is to ignore the main(). All it does is to provide the "standard" autorelease pool. When you create objects using convenience methods or by explicitly calling autorelease on an object, this is the pool that will perform the autorelease when the system drains the pool.

Variables remain in the declared scope. So if you declare an autoreleased object (or one created by a convenience method) inside a method, it will be released when you exit that method.

Dealloc should handle the releases for any objects you have explicitly retained (by using retain, alloc, etc). You are responsible for releasing those in dealloc. Also, if you have added objects to an array (which retains them), you should clean out your arrays and release them, too.

Memory fluctuations are OK, as long as everything goes away when it's supposed to. There is usually a lot of activity in the allocations, but if you look, a lot of that is probably really small bits - strings being allocated, etc. As long as everything is dealloc'd when you leave a scene (or at least everything you expect to go away), then it's probably not something to get worried about. Be sure you use the Leaks tool to check for bad behavior.

Good luck!

Hi

First of all let me say that I think cocos2d is a great framework. I am close to completing my first project but want to be sure about autoreleasing memory.

When you start a new project in Xcode using the cocos2d template, I've noticed the main.m function contains this code:

int main(int argc, char *argv[]) {

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
[pool release];
return retVal;
}

Does that mean you never have to alloc or release any variables throughout your game?
Also what is the memory scope of variables being declared within functions? Does the autorelease free them up after the function has returned?

I've noticed a lot (and I mean a lot) of allocation in the memory trace section in instruments while my game is running on my device, and that often in activity monitor that real memory increases slowly 0.1mb at a time - although I have not noticed it fluctuating more than about 10mb in total so far (starts at 31 goes up to about 41mb).

I'm also slightly unsure about what should be in my -(void) dealloc function. Can someone advise me on set practice and suggest any pitfalls to avoid in case I'm not releasing anything that may be contributing to these observations?

I found another issue , my dealloc never get called , so self retain count never runs to 0 , ok will review code.

Same problem ,

- (void) dealloc {

[spritesBgNode removeFromParentAndCleanup:YES];
//[spritesBgNode release];
//spritesBgNode = nil;

// Other stuff

[super dealloc];
}

Hmm, actually I want to ask too, do we need to manually free up the sprite batch? I mean this line

[spritesBgNode removeFromParentAndCleanup:YES];

if you remove these two lines

[spritesBgNode release];
spritesBgNode = nil;

from your playScene dealloc method does it make them visible?

Hello to everyone,

In my game i use CCSpriteBatchNode , next i will post game logic :

1. In global defines.h i create variable with name :

CCSpriteBatchNode *spritesBgNode;

// Below code playScene.m (my game scene).
2. In init create batch node

spritesBgNode = [[CCSpriteBatchNode alloc] initWithFile:@"spriteSheet.png" capacity:70];
[self addChild:spritesBgNode z:2];

3. Use batch node and add some sprites in it :

// Bomb inherit from CCSprite
Bomb *newBomb;
newBomb = [[Bomb alloc]initWithImage:@"blueBomb1.png" Type:kCollisionType_BlueNinja Position:storagePoint AndVelocity:cpvzero];
if (newBomb) {
[spritesBgNode addChild:newBomb];

[newBomb release];
}

4. After some time i want to switch scene from playScene to playScene to start next level and in dealloc i call

[spritesBgNode removeFromParentAndCleanup:YES];
[spritesBgNode release];
spritesBgNode = nil;

5. I use chipmunk2d bode and shape for each newBomb
6. When start next scene (see step 4) bombs sprite became invisible !!! I know it because with i can see in physic debug mode shapes.

I test same code without batch node just [self addChild:newBomb z:2]; and all ok , but when i use batch node sprites became invisible after [[CCDirector sharedDirector] replaceScene: [PlayScene scene]];

Any ideas ?

Thank you.

I just KNEW functional programming would be mentioned.
Well, it it hard to argue against chipmunk, because it is probably the most state of the art physics lib at the moment, and it is hard to argue against someone who has worked on large scale projects, because OOP as it is now, has its limitations. I agree to that.
OOP only works if noone breaks the hierarchy, and that is the weak spot I guess. Functional programming could probably bypass a lot of that, but I don't see it as an extension to C, as it is now.

@Birkemose: I respect what you are saying. A strong class hierarchy is indeed a good and useful tool, but there are some problems that it just doesn't solve well, and some that it doesn't solve at all. Personally I find that class hierarchies work best when they are shallow. Unfortunately in my experience, especially on large projects, class hierarchies tend to get deep, top-heavy, and bloated. I think I've become enamored with Objective-C because it provides many useful tools and programming paradigms, without becoming the bloated mess that C++ has become.

Also, it's worth pointing out passing context via a void pointer cannot even be completely avoided when using UIKit libraries, there are several functions that require you to do this.

@slembcke: +1 for functional programming. I think it will take awhile before I am very capable with a completely functional programming language, but I'm definitely happy that many aspects of it are making their way into more of the "mainstream" languages these days.

Heh. I guess I find making a weak copy of self to be fairly trivial. It is just only one line of code needed to save several and make the code organization easier. :p The only real gotcha is that you have to access the ivars explicitly, but I end up doing that all the time when passing a "self" to C functions anyway.

Anyway, it's not that often that you end up having copying and retaining blocks. So this isn't exactly that common of a problem.

/me shrugs

Blocks are definitely quite useful when working with callbacks. It allows you to throw away a bunch of gross type casting code and allows you to keep type safety. I use them quite a bit with Chipmunk. (Speaking of which I was going to write a short tutorial on how to use blocks with Chipmunk...) Much like in toadkick's example, instead of having to make a separate callback function and pass a single context pointer into it, you can just write the callback almost as if it was a for loop. When you need to pass more than one value into/out of a callback this is golden. Chipmunk has a dozen or so private structs that are used with exactly once because I can't use blocks and still make it C99 clean. I would definitely use them otherwise. I definitely would encourage people to use blocks to interact with Chipmunk, Objective-Chipmunk has a bunch of them in the API now.

I'm a functional programmer at heart, so I tend to think in closures. Blocks are about as close as you'll ever get in a language based on C. ;)

I got to agree with @Birkemose here regarding blocks. I find templates very useful, but blocks sound like quick hack to me.

Debugging with blocks is also another matter depending on the issue you are facing. I specially dislike the __block modifier, but at least it shows the block will play some trick into the variable's value.

Let alone support 3.x, which is now something in the past I guess (if not on the first version on the next couple releases of the SDK).

I agree 100% with Toad, that this is a polarized issue, and if blocks works for you guys, then go ahead.
I am an old school guy anyways ;)

The example you provided Toad, is not in my line of coding, because I would never ever put myself in a situation where I passed important function parameters via void pointers, and relied on casting. A good a strong class hierarchy with strong typing will prevent that any day. Also - and you can prove me wrong in 5 years if it catches on -, the C block syntax makes my eyes bleed. Much like templates.
It is clutter in the way that it is almost unreadable.

In my opinion, there is a fine line where you put the level of abstraction. If you lean to much towards the language, you get gibberish from reading and supporting the code, while if you put it in the class hierarchy ( as in cocos2D case ), you get an easy to understand, yet immensely flexible and powerful tool.

All this is of course all coding paradigms, and anyone can feel free to disagree.

Blocks are definitely a polarizing feature. I definitely disagree that they clutter the language like templates, having used templates many times. In fact, used properly, I find that they do the opposite and actually reduce clutter, e.g. as @Jamorn mentions, they eliminate the need in a lot of cases to create methods that are only called once for very specific purposes. In Cow Trouble I was able to write an animation event handler factory to create animation events handlers for things like playing sfx on a given frame, or linking animations together in a sequence, using blocks, which solved the problem quite elegantly compared to the hoops I had to jump through before.

Another thing that I think they do quite nicely is performing operations on collections of objects, especially when there is additional context needed. Consider a process for aggregating a bounding box using the bounding boxes of all of the descendants of a given node. Without blocks, I have to use a separate function to perform the aggregation, and I have to pass the bounding box to it using a void pointer:

void mergeBoundingBox(CCNode* node, void* data)
{
	CGRect* pRect = (CGRect*)data;
	*pRect = CGRectUnion(*pRect, node.boundingBox);
}

-(CGRect)aggregateBoundingBoxForNode:(CCNode*)node
{
	CGRect boundingBox;
	boundingBox.origin = CGPointZero;
	boundingBox.size = node.contentSize;

	[node visitDescendants:mergeBoundingBox withData:&boundingBox];
	return boundingBox;
}

whereas with blocks I can do something like this:

-(CGRect)aggregateBoundingBoxForNode:(CCNode*)node
{
	__block CGRect boundingBox;
	boundingBox.origin = CGPointZero;
	boundingBox.size = node.contentSize;

	[node visitDescendantsUsingBlock:^(CCNode* n) {
		boundingBox = CGRectUnion(boundingBox, n.boundingBox);
	}];

	return boundingBox;
}

Anyway, I probably won't change anyone's mind, but once I discovered first class functions and closures in other languages (like Lua) I've felt like there was definitely a hole in the c-type languages, and I think Obj-C's implementation is pretty decent, and I'm glad they're there.

@Blue Ether Well that's only true for this very special case. I've used blocks all over the place and have had zero problems. I'd say this is a very rare case. I still think that the benefits outweigh just avoiding this small usecase.

+1 @Birkemose

@Jamorn: But with selectors, you wouldn't be stabbing your eyes out over memory errors. :-)

@Birkemose I'd say the main usage I've been using blocks for right now is to keep my code that has one function contained within one method where otherwise it would be split up. Without blocks I was relying on selectors to get something to perform a function that may only be needed just once within that class. Mostly I've been using it to perform animation related actions and chain sequences of items together. Without it I'd have to split all that into multiple methods and my code would be much harder to read.

EDIT: I've also used it for situations where I needed a button to call a selector that requires more than one argument. I don't know how to pass multiple arguments using something like:

[CCMenuItemLabel itemWithString:@"Do Something" target:anotherObject selector:@selector(performAnAction:withThis:andThis:andThis:) withData:Object];

In this case, I have no idea how to pass all the arguments with just one data object parameter... so I resort to blocks:

[CCMenuItemLabel itemWithString:@"Do Something" block:^(id sender) {
    [anotherObject performAnAction:Object withThis:anotherObject2 andThis: anotherObject3 andThis: anotherObject4];
}];

Now I have no idea if this is good practice.

This site has a good section on blocks and memory management ... and pitfalls.
http://thirdcog.eu/pwcblocks/

With that said, I never understood what they are good for.
They clutter the language, much like templates, and I still need to see a good example, where coding is simplified by using them.

@slembcke O_o holy crap, I gotta agree with @toadkick here that if I have to go through all that every time (personally not good with C so I didn't understand the code snippet as well as I should) I'd probably avoid using it in that manner and go with a selector when I need to reference self. So far I've found blocks to be incredibly useful though I'm definitely glad it was added to ObjC.

@slembcke: Ha, yeah, that should work, but after going through all of that I probably would've just used a selector instead :) For the most part I think blocks are a terrific addition to Obj-C, and I can't even imagine having to go back to a language without first class functions and closures. Blocks have really simplified things for me in a lot of cases where it would've been much more of a pain without them. But yeah, in the case of cocos2d menu item event handlers, I do believe I'll continue to avoid them.

Actually that got me thinking... It's still slightly kludgy, but this should work an still allow assigning to ivars etc:

__weak wself = self;
self.childObject = [Child alloc] initWithBlock:^{
  [wself fooo];
  wself.myProperty = 5;
  wself->myIvar = 12;
}]

All should work fine, and it only requires making a single weak copy of self. That's not so bad. Just make sure you don't accidentally reference self or an ivar directly.

No, it's just one of those hidden pitfalls of using blocks. Not bad design on your part or a Cocos2D bug. AFAIK, there is no way to mark "self" as a weak reference to the block, though it seems like there really must be...

To get around it, instead of doing something like this:

self.childObject = [[Child alloc] initWithBlock:^{
  [self.myInstanceVariable foooooo];
}];

You can do this:

id theVariable = self.myInstanceVariable;
self.childObject = [[Child alloc] initWithBlock:^{
  [theVariable foooooo];
}];

... but what a pain, and it sort of defeats the ease and convenience of blocks.

Wow, thank you for such a detailed reply @toadkick, that really clears things up.

In fact I do have a ton of blocks being used inside a CCCallBlock action with no leaks whatsoever and this just happens to be the only time in my game where a block is used within a menu item with a reference to the menu item's menu's parent (self) and runs into this error.

By right this may be bad code design on my part as studying the code further tells me that using blocks in that scenario isn't necessary at all; a selector approach was much cleaner. I don't think I will be using blocks for menu items in this way in the future unless there's no way around it (which probably doesn't exist.)

Should this be filed as a bug in cocos2d though?

Alright, here's what I've found. A node's children aren't released until the node's dealloc function is called (which makes sense). What I was thinking of were actions: actions are stopped and subsequently released in the node's cleanup function, so it is perfectly safe to use blocks that reference self in the CCCallBlock/CCCallBlockN actions.

Menu items are a different story. If you use a block for a menu item's event hander that references the item's menu's parent (self in this case), then dealloc will indeed never be called on the menu's parent due to the circular reference. IMO this really limits the usefulness of blocks as menu item event handlers, and in fact I would consider that usage to always be dangerous because it is not obvious that you should not reference the menu's parent in the block, which creates a pit that is easy to fall into.

My recommendation would be to do what you've already done, and always use selectors for your menu item event handlers, which would guarantee that such a situation would never occur.