I am using SFML, which handles most of it’s memory through std::vector<Uint32> and other types similar to that. All declarations use the default Allocator. The SFML library is compiled into .lib files that are statically linked against in Visual Studio. (I possess all the source code to it however if needed.)
My question is, what would be the least painful method of forcing SFML to use my custom small-objects/thread-safe allocator for STL containers, instead of the default? The less I need to alter the library itself, the better of course!
Edit:
If it helps at all, forget the implementation of the library; I can recompile that on the whim. For the sake of the question, imagine it’s my code I am using. My goal is to change the default Allocator that all STL containers use, essentially.
Edit2:
If that is not at all possible, would overriding new itself be a proper method? I have read around that the default allocator is nothing more than sugar coating on the new/delete operations.
Well, the most ‘bruteforce’ or foolproof method would seem to create a preload library that implements malloc/free (and friends?)
This is usually the way in which heap debuggers/bounds checkers operate.
However, I know nothing about the SFML allocator requirements, so it might not work if the space is very limited. In that case, I suggest ‘marshaling’ (fancy word for copying) the data over to the custom-allocated regions when needed
Tangentially related:
Eletronics Art has a ‘port’ of STL for game development. It is heavilty geared to custom allocators (in fact, it comes without a default one!). You can have a look at