It's time to ask a real question.

Do I really need to shutdown Allegro at the end of a program? Destroying all bitmaps, uninstalling all addons, etc.

It makes sense I need to call al_install_system (I'm not using C, so no atexit), and init all the addons like mouse, audio, etc. But, I have all of this code to track everything so I can destroy it on shutdown, uninstall the addons, and finally call al_uninstall_system.

Now I'm faced with a context where I might want two Allegro displays so if I coded each one independently I'd install Allegro and uninstall Allegro at the end, but now I actually need a "reference counting" system of sorts so I can install twice but need to uninstall twice before it's really uninstalled.

I try to be a great "C" programmer even though I'm not using C. For every X there is an equal but opposite reaction Y (al_malloc and al_free, install/uninstall, create/destroy), but I know the OS cleans all of this up for me.

Is it really worth it? Do I really need lines and lines of code at the end of main just to free/destroy/uninstall everything? Even if I have a little fear of a fault if accidentally cleaning up something twice? I know I'll probably get laughed off of the Internet for proposing malloc without free but do we REALLY need to?

I do, but only because I think it's better engineering.

A while back I wrote a quick interface with a function pointer array and a couple of functions to add game startup/shutdown routines in pairs.

At shutdown we run a function that does a quick loop through the array up to value "count" to execute the shutdown functions. Because they're added in the correct order, they're executed in the correct order.

Do you need to do this? Well, valgrind certainly complains a bit less when I shut things down the "right" way, and that helps me debug and check for memory leaks, just by simplifying the final memory check report. This alone makes it worthwhile for me, and it's not all that hard to do.

In your own code, you can usually get away with not calling certain free/destroy functions if you know your game works fine without. This doesn't mean I recommend doing this, though. You never know who mind end up getting access to your code in, let's say, five or ten years. We're actually in the process of porting a game right now where the original developers probably something something similar. Something along the lines of "Oh well, it's just our own, internal code. It doesn't matter if it doesn't clean up properly as long as it doesn't break anything". Well, now we have that code and some of those memory leaks DID, in fact, cause problems. So in general, I don't recommend not calling all those cleanup functions. That's not only bad practice, but could actually break some things. Now for just testing something quickly, it probably doesn't matter whether you cleanup everything properly or not, but once you finalize some code, you should definitely make sure everything cleans up properly.

Now all of this goes for private code only. For public code, proper cleanup is definitely mandatory, since you never know who will use your code in the end and in what way.

The problem with this aproach is that you need to know exactly what the code you're using does internally. Now for Allegro, this may be the case. But what if you're using a different library and don't know exactly about its inner workings? It may do something very important in the destructor that would be a bad idea to skip. For example, maybe some class decides to flush user data in its destructor and skipping that desctructor prevents the data from being saved. Unless you know exactly that a certain free function doesn't do something important, not calling it should definitely be avoided. Sure, closing the application will free all memory consumed by it, but freeing memory and calling a free function aren't the same thing. A free function could always do more stuff than just freeing your memory.

If you absolutely want to tie the lifetime of some data to your main() function, then that's what classes and local scopes are for. Just create a class that wraps your calls, create a local instance of that class in your main() function and now once you leave your main() function, the appropriate free function will automatically be called. Or if you need to work with new/delete, smart pointers are also a thing.

Wait, references to all the bitmaps created by Allegro are kept internally and deleted on exit??

Even if Allegro didn't... the operating system is still going to...

Though, I'm not sure if GPU memory allocation is handled by the OS.

(I still free everything... when I remember.)

the jalleg binding itself is pure. It works just like real Allegro does except there is no al_init because there is no atexit, so user has to call al_uninstall_allegro directly. I have no questions about that. There's no "lying" going on it's a straight binding. I'm not trying to re-implement Allegro in Java or hide Allegro or hide that it's C or that it's not garbage collected.

(re atexit: actually there is a Java equivalent to atexit called a shutdown hook but I haven't fully investigated if the Allegro DLL is still guaranteed to be loaded at this time).

However, on top of the binding I am having some utility framework classes to initialize and shutdown Allegro for you, namely it remembers what addons are installed. Then it can uninstall them.

I think the topic has derived too much from the original question. It seems that the consensus is to make sure to call al_uninstall_allegro. In my examples program I'll just have to make sure not to call al_uninstall_allegro if another example is concurrently running in another display in the same process. That was really the point of the original question is if I needed to go through that effort (vs. the alternative of never calling uninstall). Since the current code already uninstalls addons I can just leave that even if not necessary.