When I first encountered BASIC, every line of code had to be numbered. So you would have something like

10 FOR I = 1 TO 10 STEP 1
20 PRINT I
30 NEXT I

This linear approach was very limiting. If you wanted to insert code into the above FOR loop, that code would have to be less than 10 lines long in order to fit. You could work around this using GOTO commands or increasing the distance between line numbers (e.g. using 100 instead of 10 and 200 instead of 20) - but the problem always remained.

This kind of BASIC is ancient history. It's the way I was doing things in 1981. Nonetheless, this history had left an imprint upon my psyche, leading me to suppose that BASIC (given its origins) could never be truly object oriented. It could be clumsily simulated, rather than natively embraced.

When I first saw BlitzMax's user-defined Type Object system, which is the heart of Blitzmax OOP (object oriented programming), I was thus dubious. As I step into my current project, however, I am noticing an interesting thing occurring. My new Blitzmax code is actually simpler and more tightly object oriented than my C++ had ever been!

Now I'm the first to admit that this is more because of my idiosyncrasies, than any inherent deficiency in C++. When I shifted from C to C++, the similarity of the languages enabled me to carry on many old procedural habits into my C++ code. I excused these, saying to myself that these old methods ran faster - but deep down I doubted this excuse, and the reality was that I'd never properly sat down and attempted C++ in complete isolation from C. If you were to look at my game code, you'd thus see an eclectic mix of old and new coding styles - that certainly work - but actually are clumsy, needlessly repetitious and bloated compared to a pure OOP style.

What has happened with my switch to Blitzmax is that I have been forced to "unlearn" my previous C experience. I can't cheat and rely on old knowledge, since in this arena, it doesn't apply. This has been extremely refreshing - and indeed rewarding. Strangely I am even enjoying the bare-bones IDE that comes with Blitzmax, simply because it is a completely different environment in which to work. Everything is new, everything is fresh, and my code is reflecting this.

Suddenly I'm using OOP inheritance and polymorphism everywhere, to produce (fairly!) clean and (comparatively!) small code modules. Freed from the tyranny of platform dependence, I no longer fret over the obscure ways Microsoft APIs often use to implement what should be simple and straightforward procedures. In short, far from being a pseudo OOP language, Blitzmax has actually revolutionized my coding style, making it far more object oriented AND increased my productivity. Which is just wonderful!

In my Astariel C++ code, I have a setup section where I make calls to initalisation code in about 100 different classes. They run along the lines of:

SAFE(D3DBullets.One_Time_Init(), "Main::One Time Init - D3DBullets.One_Time_Init FAILED");

These calls typically reserve and initialise blocks of memory. Like this:

 // CONSTRUCT THE RESERVOIR
 Reservoir = (Bullet *)(D3DSage.Malloc(BULLET_RESERVOIR_SIZE * sizeof(Bullet)));

Then, in the game closing code, I have a corresponding Cleanup section, again stepping through each of the different classes, this time in reverse order, freeing everything:

 So D3Dbullets.Cleanup() calls:

 // DESTROY THE RESERVOIR
 if(Reservoir)
  D3DSage.Free(Reservoir,BULLET_RESERVOIR_SIZE * sizeof(Bullet));

This is all very standard and familiar to C++ users.

But take a look at Blitzmax code, particularly the example code, and you tend to see a striking absence of cleaup code at app close.

So you'd see:

 Bullet:Tbullet = new Tbullet

To reserve a user-defined bullet type object (think c++ class) in the Init section. But at the end of the code you'll most likely see just this:
 
 End

Huh? What gives? Sometimes, even more confusingly for the C programmer, you'll see:

 Bullet = Null

Shouldn't there be a Delete, or a Release or a Free in there somewhere? This doesn't look right at all!

What is actually occurring here (at least so the manual leads me to believe) is that the Blitmax engine keeps a reference count of all reserved memory. As soon as objects in memory are no longer directly referenced, the memory is queued for automatic release. Assigning Bullet = Null is thus 'de-referencing' the memory block, which will in turn let Blitzmax know it needs to be freed. The program End statement automatically de-references and frees all objects. So in practice, you rarely need to worry about freeing up your reserved memory, Blitzmax does it for you.

For me, this has been extremely disconcerting. Such has been my C++ training and habits that I feel decidedly uneasy leaving memory management to Blitzmax in this manner. All the examples look (from a C++ perspective) like sloppy code, as there are no cleanup sections. And calls to functions that use local variables to reserve memory, without then freeing that memory, still give me the heebie-jeebies. But in fact such code doesn't normally need a cleanup section. Local function variables are automatically de-referenced when they go out of scope at function close.

After a while, you begin to realize how much neater this is. Less cleanup code means less code. And the less code you have to maintain the better.

The only issue you really need be concerned about is when using the =Null option to free up an object. You just need to make sure you are not still referencing this object elsewhere in your code, otherwise you will be thinking you have freed an object, when in fact it is still live. Normally in C++ the problem is the other way around. You free an object but then still try to reference it elsewhere, causing all sorts of nasties.

So, freaky though it may look at first, the Blitzmax memory management system actually minimizes memory leaks. Which means your code is smaller and your obscure bugs fewer. Which is great! But still freaky…