Changelog

• Fix memory freeing on destruct #13
• Merge MemoryPoolData.h into MemoryPool.h, separation is unnecessary. #14

Future Features

• Garbage collection mode. While developing using my MemoryPool, I decided to do some weird taboo and override the new and delete operators completely to use a global MemoryPool of the application. Then, I noticed that the pool just keeps filling up since memory is allocated and de-allocated almost randomly by libraries and the system, thus is not sequential as the pool likes it. Using the memory pool scope feature won't help me here - so I decided to add some garbage collection mechanism that keeps a linked chain of all free area in the pool that can be used for further allocation - this seemed to work great so I decided to add it to the library later.
• Thread safety mode When I was developing a server application, that obviously requires to do work in parallel, I also had the Idea to override the new and delete operators to speed things up a little. This also required me to add changes to the memory pool, once it will be complete I will also add it to a dedicate release :)
• Advanced garbage collection mode The garbage collection feature changes the header of SMemoryUnitHeader to a special header that indicates that the unit was deleted, and is pointing to the previous deleted element (this way the MemoryPool keeps track of all the available deleted data). In advanced garbage collection mode, we want the memory pool, when memory is released, to iterate the deleted units and merge the ones that are close to each other into single units. Accordingly, the freeing procedure will have more latency but will be more optimized for memory consumption while still keeping a speed up over regular memory allocations.

Discussion

Discussion is open about the algorithms used in the MemoryPool that can be affective and speed up the library even more. Personally, I have a couple of different ideas regarding the garbage collection of the pool that can come in different forms and performances and would love to hear your ideas too! :)

When freeing a block in the middle of the block chain of the pool, the next block didn't connect to the previous block correctly, which might cause a memory access violation if more that 2 block are freed in a chain in a certain order.

CPPShift::Memory::MemoryPoolManager no longer present. Right now the MemoryPool object holds all the functions to handle the memory pool data structure.

• Create a memory pool using auto mp = new CPPShift::Memory::MemoryPool(size); or auto mp = CPPShift::Memory::MemoryPool(size);
• Allocation, re-allocation and de-allocation are now new (mp) Type[size];, mp->reallocate<Type>(pointer, size); and mp->free(pointer) respectively.
• Allocate & re-allocate now have two modes: templated and general -> mp->allocate<Type>(size); or (Type*) mp->allocate(size * sizeof(Type)), and mp->reallocate<Type>(pinter, size) or (Type*) mp->reallocate(pinter, size * sizeof(Type)). These 2 approaches to each function are actually the same.
• Manage scopes using mp->startScope() & mp->endScope()
• Got slightly better performance (from a maximum of 22 time better to a maximum of 24 times better depending on OS & compiler)

The header & code files for adding the memory pool to your project.

Features:

• Create a memory pool: CPPShift::Memory::MemoryPool * mp = CPPShift::Memory::MemoryPoolManager::create(size);
• Allocate in pool using new: Type* my_type = new (mp) Type[size];
• Smart de-allocate & re-allocate memory in the pool: CPPShift::Memory::MemoryPoolManager::free(my_type) & CPPShift::Memory::MemoryPoolManager::reallocate(my_type, new_size) respectively.
• Scope allocations together to free them together: CPPShift::Memory::MemoryPoolManager::startScope(mp) & CPPShift::Memory::MemoryPoolManager::endScope(mp)
• Smart freeing of memory blocks for you while hiding implementation details
• Very fast solution for allocations of different sizes & types