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.)

nine comments, already:

no need to apologize when offering such precious data :D
andrei25ni () (link) - 16 05 06 - 00:02

STL already solves this for you, on another note. ;)

What I really wanted to ask: When do you plan to start visiting the forum more often? I just now discussed in the IRC channel, what possible improvement to Irrlicht I could start. I’d propose it in the forum too, but as long as I can be almost sure, that such a call will go by unheard, since the only person, who decides how the engine is gonna develop doesn’t read it anyway, I can’t be bothered.

Please, please, pretty please: comment on the huge amount of propositions and bug reports and bugfix patches in the forum. It is now over a month after you made the indication, that you’ll visit the forum more often. And in this time you had exactly (drum roll please) one forum post. The forum plays a vital role for the engine’s user base and the frustration in parts of the active community can almost be seized with bare hands.
Baal Cadar - 16 05 06 - 00:03

Not to say “I told you so” (although I did in detail :P ), but this is the very reason I have ported Irrlicht to use STL rather than the internal container classes. On the upside, using the STL classes to replace the Irrlicht containers allowed me to bring in containers not yet implemented (i.e. std::map) and to use the STL optimised search & sort functions :)

On a more serious note, Baal Cadar does bring up something very important to the Irrlicht community. That is, the only developer with the rights to change the official branch of Irrlicht is not involved at all in the community he set up. This has serious effect on the morale & momentum of the project. This is something I have had to consider recently, because I have considered branching Irrlicht simply to get all the bug fixes implemented that have been posted in the forums but never merged into the official source code. If you (or at least someone with commit rights to the CVS) were actively involved – I wouldn’t bother. The codebase (aside from a few niggles, like the allocator thing) is great and easy to use. It’s just that great contributors are being ignored and that turns away a significant number of them :(
Eternl Knight () - 16 05 06 - 03:38

I think all things already said which I’d have said on this topic (Irrlicht development, not memory handling ;) except that there are several developers with CVS access which don’t participate in the forums, even don’t use CVS regularly. Just branch a development version in the CVS and assign one of the active forum experts the management of this version.
hybrid - 16 05 06 - 13:08

yummy pictures…too bad UModel 2006 isn’t open source…
*YIKES!* $ 129.00 without support package! :(
lug - 16 05 06 - 15:38

okay, back ontopic.. good to see you’re thinking about allocators!!! memory management has been one of my biggest sticking points with irrlicht… but now, looks like thats gonna be fixed :-D
RabidLockerGnome - 16 05 06 - 16:58

yeh i never used the internal containers, I always just linked in the STL for my exe and used those instead. I understand why the irrlicht containers are there, to ensure that they are portable, but still, is the implementations of the STL THAT different in Windows vs. Linux that this is necessary?
also if niko can be on the forums more that’s great, but he does also have a real job/classes and stuff to do, so i understand if he can’t spend every waking moment in the forums. I think what is really at issue here, is perhaps its time to give some of the other devs commit access, and make sure somebody is usually around on the forum who could be considered an “expert”.
buhatkj - 16 05 06 - 20:31

Why didn’t you write this post 6 months ago! :)
Mike - 16 05 06 - 21:57

yep, brb into the forum soon. just some stuff to do currently.
niko - 18 05 06 - 18:14

Remember personal info?
Email (optional):
URL (optional):
Enter "layered" (antispam):
Comment:Emoticons / Textile

  ( Register your username / Log in )

Notify: Yes, send me email when someone replies.  

Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.
Note: If you type in your email adress above, it will be visible to other visitors, although it will be hidden for bots using javaScript.