Jump to content
  • Advertisement
Sign in to follow this  
Gaiiden

Issue with delete

This topic is 5134 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

Okay, I have a pointer to an SDL_Color struct to hold the color data for my text:
SDL_Color* m_pForeColor;
All well and good. Now when I load the text from the data file I load in the RGB values and do this:
m_pForeColor = new SDL_Color;
m_pForeColor->r = iRed;
m_pForeColor->g = iGreen;
m_pForeColor->b = iBlue;
Ok kool. So now I want to change the colors. So from the user-side of things I do:
SDL_Color* pColor = new SDL_Color;
pColor->r = 255;
pColor->g = 0;
pColor->b = 0;
pText->SetForeColor(pColor);
and on the engine side:
void SetForeColor(SDL_Color* pNewColor) 
{ 
	if (m_pForeColor)
		delete m_pForeColor;

	m_pForeColor = pNewColor; 
	m_bTextChange = true; 
}
is this the proper way to be playing around with pointers? The reason I ask is because for some reason VC++ breaks the app at the delete call in the above function after I've changed the text color for the second time. m_pForeColor is a valid pointer (at least, it's not 0), so I don't get why it's having trouble. So again - I load the text object and allocate memory off the heap. Fine. I change the text color, which deletes the old memory and assigns the new memory allocation. Good. I change the text color a second time, and when it tries to delete the memory block, it dies. [help] [smile]

Share this post


Link to post
Share on other sites
Advertisement
No, it's just linking to a static library.

Anyways I found the problem. Something stupid as always [smile]. I was calling two color change functions with the same pointer. I clipped the second function call out of the original code snippet, since that wasn't the function where the break was:

SDL_Color* pColor = new SDL_Color;
pColor->r = 255;
pColor->g = 0;
pColor->b = 0;

pHealthRect->SetRectangleColor(pColor); // DOH!!!
pText->SetForeColor(pColor);

SetRectangleColor has the exact same code as SetForColor (basically) meaning that SetRectangleColor is deleting the same pointer being used by SetForeColor, hence when it's SetForeColor's turn to delete, we get an error.

Now, I could fix this by setting the pointer to zero before deleting it, so the next function won't delete the pointer, but that doesn't solve the problem that after setting them both the first time, if I change the rectangle color, I will also adversly change the text color! So I would have to do:

SDL_Color* pRectColor = new SDL_Color;
pRectColor->r = 255;
pRectColor->g = 0;
pRectColor->b = 0;
pHealthRect->SetRectangleColor(pRectColor);

SDL_Color* pTextColor = new SDL_Color;
pTextColor->r = 255;
pTextColor->g = 0;
pTextColor->b = 0;
pText->SetForeColor(pTextColor);

That seems like a pain. I'm using pointers since these are game objects, and there could be a lot of them, and I don't want to run out of stack space. But is there a better way I could do this?

One question leads to another [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by Gaiiden

That seems like a pain. I'm using pointers since these are game objects, and there could be a lot of them, and I don't want to run out of stack space. But is there a better way I could do this?

One question leads to another [smile]

No, it won't be stack allocated. The initial object you pass will be, but if you assign it to an instance of the SDL_Color structure that is already in the class, then it will be copied to the heap instance (since i'm assuming pText is a heap allocated object).

Honestly, you're losing more through that allocation than you're gaining. It will exist on the stack for only the briefest of moments.

Share this post


Link to post
Share on other sites
Well my first instinct would be boost::shared_ptr. That would help prevent most of the memory errors.

But, all things considered, a SDL_Color is a really small structure, so I would just store it by value in the first place.

Share this post


Link to post
Share on other sites
Thx guys! Cool I didn't know that it would tack itself on to the heap space of the text object. Very nice. Of course this means I have some code fixing to do to rip out these pointers. *sigh* [smile]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!