Odin has a builtin heap allocator that works the same way you would expect any other high-level language to do memory allocation–it's just that you have to free the memory yourself. Plus, Odin's built in `context` system makes it really easy to change what kind of allocator is used for different sections of code. For my use cases, I've never needed any more than a heap and an arena, detailed in this talk:
Personally, my large Odin project uses a series of arrays to store specific data, and then everything else is stored in a temporary allocator, which is wiped between frames. Besides some graphics initialization & path resolution at initialization time, the heap allocator is never used. I never really have to worry about memory. That's similar to the design detailed in this talk by Ryan Fluery:
Odin also has a tracking allocator which can be used to check for leaks or double frees. In debug mode, my program will print out all un-freed memory left after shutdown. If you're working outside of Odin, I've heard good things about Valgrind for C/C++:
https://www.youtube.com/watch?v=nZNd5FjSquk
Personally, my large Odin project uses a series of arrays to store specific data, and then everything else is stored in a temporary allocator, which is wiped between frames. Besides some graphics initialization & path resolution at initialization time, the heap allocator is never used. I never really have to worry about memory. That's similar to the design detailed in this talk by Ryan Fluery:
https://www.youtube.com/watch?v=TZ5a3gCCZYo
Odin also has a tracking allocator which can be used to check for leaks or double frees. In debug mode, my program will print out all un-freed memory left after shutdown. If you're working outside of Odin, I've heard good things about Valgrind for C/C++:
https://valgrind.org/