Too many memory leaks and a line that cause fast memory usage growth

[PetrosPastor]

Hi
There are many memory leaks at the codes
and there is a line that cause fast memory usage growth that i find it where you set UILable varibles:

label.getComponent().SetLabelText(ss.str(), "arial");

which it call this function everyframe:

void SetLabelText(std::string text, std::string font)
{
SDL_Surface* surf = TTF_RenderText_Blended(Game::assets->GetFont(font), text.c_str(), textColour);
labelTexture = SDL_CreateTextureFromSurface(Game::renderer, surf);
SDL_FreeSurface(surf);
SDL_QueryTexture(labelTexture, nullptr, nullptr, &position.w, &position.h);
}

when i command out the line memory usage remain on 31 mb, but if you let this line run in the program memory usage will increase until it crash.

And I found too many memory leaks with crtdbg.h library that I dump it in a text file:

dump.txt

[jmarcher]

@pedrodarko as a rule of thumb always try to pass a const reference to std::strings. Here is the perfect case for that...
void SetLabelText(const std::string& text, const std::string& font)

You can apply this to more std::string parameters around the engine

[jmarcher]

@pedrodarko I discovered the memory leak compiling the original BirchEngine, replace your draw() function call on the UILabel: (names may be different) but you will need to destroy the texture after you copy it.

void UILabel::draw()
{
    SDL_RenderCopy(Game::renderer, this->labelTexture, nullptr, &this->position);
    SDL_DestroyTexture(this->labelTexture);
}

[PetrosPastor]

@pedrodarko I discovered the memory leak compiling the original BirchEngine, replace your draw() function call on the UILabel: (names may be different) but you will need to destroy the texture after you copy it.

void UILabel::draw()
{
    SDL_RenderCopy(Game::renderer, this->labelTexture, nullptr, &this->position);
    SDL_DestroyTexture(this->labelTexture);
}

Hi. thanks for your reply I appreciate it .
This solution works very well.

[Achylles]

I've noticed that Carl doesn't use delete after allocating dynamic memory to a raw pointer with new
Shouldn't auto ptr = std::make_unique<...> be used instead?

[jmarcher]

Which Pointer do you mean?

[Achylles]

@jmarcher

In Game.cpp lines 18 and 63 he uses new, but never uses delete afterwards. This will (obviously) cause memory leaks.

From what I know, if you decide to dynamically allocate memory with new, then the class destructor won't clean up the object automatically. The only way to ensure that you don't constantly use up fresh blocks of memory without releasing the old ones is to remember every time you use a raw pointer and manually delete it, or to use a smart pointer, which will automatically do that for you.

Basically std::unique_ptr or std::make_unique may have a slight overhead, but most people say it doesn't. So I guess it's pretty much as fast as using Map *map = new Map(...)

Some people just prefer the old syntax because they are old school and would prefer not to transition to modern c++. That's obviously fine as long as you know what you're doing. It's basically like driving a manual transmission car.

[jmarcher]

@Achylles It will not cause memory leaks, I mean yes, every time you write new Class you should think in writing the delete part of it, but in this case both of those are called one time only and never need to be deleted until the game is finished.