Sorry your browser is not supported!

For those that appreciate a good memory manager, here's a custom reference-counting memory manager for DBPro. It incorporates a quadratic probing (open addressing) hash table for fast mapping between pointers and reference counts. Originally designed for a Perl-style OOP solution, it is robust, eliminates memory leaks and provides good debugging functionality.

This version hasn't been thoroughly tested but I believe it works without problem. It won't, however, work on versions of DBPro prior to 1.58.

Read the comments in the attached code for more information.

what do we use it for?

My original motivation for developing this was to aid in introducing Perl-style object-oriented programming into my work flow. In Perl, objects are blocks of un-typed memory whereby class attributes and methods are accessed/implemented via simple functions calls. Through this I can also emulate other OO concepts such as inheritance and polymorphism.

Additionally, you can also break away from the need for globally visible data and finally write truly modular sections of code.


The other big use for it is in creating multi-tier (logical or physical) data caches for game data. Have you ever wondered how you can move seamlessly through massive lands in epic online role-playing games? How about a detailed FPS game that manages to use hundreds of megabytes of textures in a single level despite not having nearly enough space to hold them all on your graphics card (or indeed in system RAM)? These are done through data caches.

In the FPS example, texture data can exist in three physical tiers - on the hard disk, in system memory and in video memory. When the game predicts that a texture resource may soon be required, it will load it quietly in the background into the second tier (system memory). When it finally needs it, it is placed into the final tier (video memory) for rendering. When it has no more immediate use, it is removed from this tier to free up video memory but is kept in the second tier in-case it is needed again in the near future. When there is no chance that the texture will be used anytime soon, it is removed from system memory to free up space for other data resources that actually need it.

In this way, huge amounts of data can be seemingly utilised on resource-limited machines. This memory-manager is easily adaptable to manage caches such as these.


If nothing else, the pointer-reference counting functionality of this code coupled with its robust pointer dereferencing and memory deletion features is reason enough to use this memory manager. This is because it makes working with dynamic memory safer and easier to profile and debug.

The hash table implementation that makes up the bulk of the code has a billion-and-one uses in programming. It can be adapted to suit a variety of needs such as fast indexing in game databases, maintaining symbol tables in semantic analysis (script interpreters) or simply just used as an associative array.

Very nice DSG! I can definately use this. I can also learn a lot from your code. Very well organized and it sounds extrememly complete; as in bug/idiot-proof.

I saw/read your rules. I will probably want to include this in the Open MMORPG project for use with our inventory system, so your name will be added to the credits list. If you want to check it out, just click on my sig and go to the forum.

Thanks, I'm glad that someone found it useful

The MMORPG project looks interesting, I'll be keeping an eye on it as it progresses.

Looking through all that code. I have to say that I like your overalll structure. Very readable. That said, I still don't get everything that is going on.

Anyway, I did notice these lines, here;



Since your code is structured to be used like a language, I figured you might find this suggestion useful: You can use a constant in place of that function, like so:

#Constant mmInitialise mmInitialise2( 11 )

Now, the user does not need the () at the end, making it a tad easier, and gives mmInitialise more of a built-in command feel.