You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, I was looking over the source and there seems to be a large use of raw pointers which could be avoided through the use of smart pointers. These will define ownership for every object in the game while also avoiding manual deallocation and possible memory leaks or double frees.
For example, in Game.h:131 a map object is stored as a raw pointer and passed to objects. This could be converted to shared_ptr's or even better stored as a unique_ptr in the Game class and delegated as references. In this case, this would work quite well, as the objects that require it ensure that it is passed through the constructor, so it is allowed to be stored as a reference in the class instance.
If you're interested in making this switch, which I personally think will improve the projects architecture and remove memory issues later down the line, let me know. I'm more than willing to do the all initial work.
Thanks.
The text was updated successfully, but these errors were encountered:
Definitly a good idea, I haven't put many efforts into it because I focused on functionnalities & reversing, but you're more than welcome to clear the code up.
Hey guys,
So, I was looking over the source and there seems to be a large use of raw pointers which could be avoided through the use of smart pointers. These will define ownership for every object in the game while also avoiding manual deallocation and possible memory leaks or double frees.
For example, in Game.h:131 a map object is stored as a raw pointer and passed to objects. This could be converted to shared_ptr's or even better stored as a unique_ptr in the Game class and delegated as references. In this case, this would work quite well, as the objects that require it ensure that it is passed through the constructor, so it is allowed to be stored as a reference in the class instance.
If you're interested in making this switch, which I personally think will improve the projects architecture and remove memory issues later down the line, let me know. I'm more than willing to do the all initial work.
Thanks.
The text was updated successfully, but these errors were encountered: