Memory management for static variables

Hi, I am new to Cocos2d-x and I am still getting used to creating and initializing classes without constructors. I have read up on the memory management and autorelease pools, but I have a couple of questions:

First of all, do you add everything to the autorelease pool or do you sometimes use constructors and destructors aswell.
Further, how do static variables interact with the autorelease pool? Say I have a class managed by an autorelease pool and I want to assign it to a static variable of another class like so:

static MyClass* var = MyClass::create();
this->addChild(var); // is this even necessary?

What happens to var once all instanced of MyClass are released? Do I need to add var as a child to avoid it getting deleted automatically?

1 Like

If you want to make sure an autorelease object isn’t released, then simply call retain() on it. When you’re done with it, call release(). There must always be a matching release() for each retain() that is called on the object. Look up the details of those functions to understand what they do. There are plenty of comments in the CCRef.cpp and CCRef.h files on how this all works.

Aside from that, what reason is there for you to want to use statics for these types of objects? If you’re thinking of making these as global variables, then I strongly suggest you re-think your design.

2 Likes

or maybe use a dreaded singleton to at least not make everything static.

2 Likes

Do it like @R101 said.
var->reatin(); //adds 1 to the reference counter
var->release(); //subtracts 1 to the reference counter

Maybe I expressed myself poorly, I don’t want to create a static class, I have a static member of type class. I am trying to implement a state machine and I follow the guide from gameprogrammingpatterns where he uses static variables to create instances of the different states the player character can be in.
I could make them non-static as well, I might even need to do so for some of them, but I’d still like to understand how to use static variables in cocos2d-x.
My problem right now is that when I define the static variable in the .cpp file I cannot add it as a child or retain it, as I am in no scope (or can I)? I just define it via Type* MyClass::var = Type::create();

You expressed yourself perfectly, it was me who misunderstood it, that’s why i edited the answer because there was not need to explain a static class.

Well i need to read that post to understand what you trying to do. But as soon as you create the class you have scope to call retain, idk where are you declaring it? so idk why u cant call release.

You need to call retain() on it somewhere, like in a method that gets called after that static object is instantiated, but now this brings up another question, why is your class inheriting from cocos2d::Ref? What is the purpose of doing that? Do you have a specific reason for this?

The state machine in the article you linked is simply creating static instances of the states, and that is completely fine, but what does that have to do with cocos2d::Ref?

@R101 That’s a good question. I don’t think there is a reason, once I learned about the automatic memory management from cocos, I started inheriting every class from a cocos type. I guess there is no real reason to do that and I should put more thought into it.

Thanks for your answers, I’ll see what I can do over the weekend and reopen the post if I still have problems :slight_smile:

Hey, I removed the dependency on cocos2d::Ref and now it works like a charm. Thanks for the hint @R101. I’m probably lacking resources somewhere now, so if you’ll excuse me :wink:

You can always take an entity-component design approach. I used to sub-class everything too when I started and as zi wrote more and more games I found ECS design worked better for my needs.

Thanks for the suggestion @slackmoehrle. For now I’ll stick to my current approach, as I want to focus on getting the game off the ground so that I can learn how to make simple mechanics feel good (how to make a game juicy :yum:). But I’ll definitely keep it in mind and might try it in my next project, which will most certainly more ambitious.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.