Allocators and what they do

If you are a C++ programmer, you might have used the STL already. And if so, you might have come to a point where you saw classes named Allocators. In short, those simply are objects wrapping new() and delete().
Why would you need such a thing? You can do several useful thing with that, for example optimizing the speed of your containers by using some sophisticated allocation scheme. Or even better: Preventing that your application crashes at certain points, when you are using template containers through different modules, like different .exe and .dll files. Simple example:

In this sequence diagram above, a program named main.exe is asking a module named Irrlicht.dll the return some text. Irrlicht.dll is doing this by creating a string object, which then allocates some internal buffer to store the characters. The string objects is returned to main.exe and then destroyed afterwards to free the allocated memory holding the strings characters. The problem: Because string is a template object, the delete() call is done inline for the heap of the main.exe. But because the memory has been allocated in the irrlicht.dll heap before and not the main.exe heap, the application will crash. That's not nice at all. Solution:

The difference is obvious: The string is not allocating its memory by itself but delegates this to an Allocator. This class is able to allocate and deallocate the memory from the right heap, and the container won't crash anymore. Really simple.
Last week I implemented this for the most important Irrlicht containers with the result that they now work independently from the heap where they have been created. And the concept of Allocator objects really is useful: Because at some places of Irrlicht you can be sure that a container never will get used in another heap, I was able to write a second Allocator object which ignores heaps and can allocate memory a bit faster. (Of course with the constraint that it never will be used in another heap, otherwise it would crash.)
I never had problems with Irrlicht containers and different heaps before in programs I wrote, but because the Editor I'm currently writing is exchanging a lot of data with Irrlicht it has become necessary. Sorry that this took so long. :)
(BTW: I created the diagrams with UModel 2006, Altova's UML tool.)