I don't see the point of hiding the implementation of something which should be as simple plugging an integer into whatever optimal data structure your code requires.
PureGDK, for example, has taken the PureBasic approach (this is for all PureGDK supported languages, C++ included!)
Normally you would create a cube like this:
You are required to specify the number twice if you want to store it in something. Or maybe you put it in a variable first. Bravo. However, your code now requires human intervention to handle your IDs.
Ok, so how about using some kind of iterative counter? But now you have to keep track of the allocating and freeing. Maybe you like this kind of control. But what if you want something a little more automated?
int objectID = dbMakeObjectCube(GDK_Any, 20)
GDK_Any is a constant of value -1. If specified then the engine will take care of finding an appropriate ID for you. And if you pass a variable or constant integer yourself, that number will be returned to you for very easy assignment on allocation.
An added bonus is that this type of implementation is not hidden. It is described within the plugin used to build the headers for the target language. So if you prefer to use your own implementation, reference counting perhaps, or some custom "handle" or wrapper object, you're more than welcome to override the function's behavior.
For example, by applying an override template parameter and reimplementing the ID allocation and return type, you can perform something like this:
DBPObject object = dbMakeObjectCube(20)
My solution in PureGDK was to provide what I felt was an optimal solution while still allowing the functionality to be overridden.
If reading this thread has shown me anything it's that everyone has their own opinion about which implementation would be most appropriate. Hiding the implementation hurts innovation.
If you really want some kind special kind of handling then instead of requesting a sweeping change in the engine, why not just implement it yourself?
Quote: "So is hero a integer relating to an object number, is it a type, is it an internal structure, is it a pointer?"
I suggest keeping it an integer. We all know what a number is, how to compare it, how to increment it. If you want it to be something else then wrap it up into your favorite data type.
Quote: "Another alternative is to use some sort of small-object allocator, as each of these handles are only 4 bytes in size (not tested, but it looks right)."
IanM, I do realize that you're just comparing methods but if you really want to do something fancy for DBP, please at least keep the engine exported as C function calls (please don't pass or return any objects) so those of us who prefer a more open implementation don't have to jump through hoops to get a simple object identifier.