Sign in to follow this  

Class design and memory (de)allocation

This topic is 4417 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, I'm trying to make some useful classes and hopefully improving my programming. Right now, I'm making a sprite class. So far, I think a sprite class should be a resource, limited to loading an image, colorkey info and blitting. Then later I hope to improve my programming and derive some richer classes of it, such as animated sprites. Now I have a question as to how the memory (de)allocation should be done. I guess, because I use the SDL api, loading an image means [heap] allocating memory for a sprite. Then as I see it I have two options for deallocation: 1) Free the surface (the image) in the sprite's destructor, relying on proper scoping for memory management? 2) Implement some Sprite.Release function, which gets called by a higher level Manager class or something? Design besides, I couldn't find out what will happen if sprites that deallocate memory in the destructor would get stuffed into something like a std::vector. If one would clear out that vector, will the destructors get called? I would guess so, but I don't like guessing too much. As you see, I know some C++ and SDL, but still have some trouble with programming, in the sense of seeing the bigger picture a sprite should be part of. Also, am I on the right track here? I seem to like to make smaller classes first and then higher level ones. For example, first some sprites, then maybe later I'll start thinking about 'Manager' classes... Thanks for your time.

Share this post


Link to post
Share on other sites
I made a sprite class, too...

Now, I didnt get what you meant.. The user doing sprite* sprite = new sprite;, or you doing the SDL_Surface* stuff in the destructor?

What I did was something like this, which can maybe get you started:

class Sprite
{
SDL_Surface *m_Sprite;

public:
Sprite(): m_Sprite(NULL) {}
~Sprite()
{
if(m_Sprite)
SDL_FreeSurface(m_Sprite);
m_Sprite = NULL;
}

//other drawing, getting, w/e stuff
};


The class can handle the SDL_Surface* by itself, so you won't need some cheap init() and deinit() functions.

As far as I know, when you pop_back() or clear() a vector most likely the destructors are called, no? Please correct me.

Good luck.

Share this post


Link to post
Share on other sites
Quote:
Original post by DeadXorAlive
Hi all, I'm trying to make some useful classes and hopefully improving my programming.


Good, most people just want to make games, and ignore the learning needed to do that effectively.

Quote:

Right now, I'm making a sprite class. So far, I think a sprite class should be a resource, limited to loading an image, colorkey info and blitting. Then later I hope to improve my programming and derive some richer classes of it, such as animated sprites.


Personally, I would just have the sprite derive from a base class that also is the base for something like the animated sprite... But otherwise limiting the sprite to a resource is a good idea.

Quote:

Now I have a question as to how the memory (de)allocation should be done. I guess, because I use the SDL api, loading an image means [heap] allocating memory for a sprite. Then as I see it I have two options for deallocation:
1) Free the surface (the image) in the sprite's destructor, relying on proper scoping for memory management?
2) Implemented some Sprite.Release function, which gets called by a higher level Manager class or something?


That about sums it up. How you handle the destruction likely depends on how you do the creation, but I've seen both.

I just redid this sort of thing yesterday, and currently stuff the surface/image into a boost::shared_ptr, which takes care of the de-allocation for me. That's a third option.

Quote:

Design besides, I couldn't find out what will happen if sprites that deallocate memory in the destructor would get stuffed into something like a std::vector. If one would clear out that vector, will the destructors get called? I would guess so, but I don't like guessing too much.


Yes, they'll get called.

Quote:

As you see, I know some C++ and SDL, but still have some trouble with programming, in the sense of seeing the bigger picture a sprite should be part of.

Also, am I on the right track here?
I seem to like to make smaller classes first and then higher level ones. For example, first some sprites, then maybe later I'll start thinking about 'Manager' classes...


Except for manager classes, that's a pretty good way to go. Manager classes are a little different, as the actual thing being managed often depends on the manager.

Share this post


Link to post
Share on other sites
Quote:
Original post by agi_shi
Now, I didnt get what you meant.. The user doing sprite* sprite = new sprite;, or you doing the SDL_Surface* stuff in the destructor?

I meant the same what your code did, except that there's an alternative: some other class does what the sprite destructor does. So that class has control over the sprites. I was unsure about what the best option was and if I got them right.

Quote:
Original post by Telastyn
Personally, I would just have the sprite derive from a base class that also is the base for something like the animated sprite... But otherwise limiting the sprite to a resource is a good idea.

I have something like that stubbed out. I have a BaseSprite, then both StaticSprite and AnimatedSprite inherited from BaseSprite. However, it sounds like you say it's better to have some abstract base class (pure virtual right?) so that only the derived classes will actually be used. Did I understand that correctly?

Quote:
Except for manager classes, that's a pretty good way to go. Manager classes are a little different, as the actual thing being managed often depends on the manager.

Good to know, that was what I suspected.

Thanks for the replies. Maybe I just go write three versions for practice.

Share this post


Link to post
Share on other sites
Quote:

Quote:

Quote:
Original post by Telastyn
Personally, I would just have the sprite derive from a base class that also is the base for something like the animated sprite... But otherwise limiting the sprite to a resource is a good idea.


I have something like that stubbed out. I have a BaseSprite, then both StaticSprite and AnimatedSprite inherited from BaseSprite. However, it sounds like you say it's better to have some abstract base class (pure virtual right?) so that only the derived classes will actually be used. Did I understand that correctly?


Well a sprite object is [simplistically] made of two smaller parts. A renderable part, and the surface/image part. The rendering does the actual drawing [or provides an interface for something else to do the drawing], and the surface/image part keeps a reference to or the actual data which the rendering part uses to draw stuff.

Often the surface/image part is controlled by a manager, so that you can reuse images, and that the actual loading of them can be controlled outside of the rendering code.

What I meant is that the 'renderable' part is often best as a smaller baseclass since there's so many different things to render, and it's so useful to have a common interface to them all. And by inheriting them both from the renderable base class, you can just swap out the surface/image part with a animation part pretty cleanly. Better yet, you then have a common interface to them both [as well as significantly different renderables like text] so you can easily handle them all.

Share this post


Link to post
Share on other sites

This topic is 4417 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this