Quote:Original post by sb01234
I've often heard that using IDs has fallen out of favor, and that storing pointers (or smart pointers) directly to the objects is often preferable. However, IDs have some nice properties, such as [1] the convenient possibility to query whether an object has stopped existing, and [2] the ability to force destruction of an object when it mustn't exist any longer. Sometimes this is preferable to having shared pointers which do the opposite: force keeping the object alive up to a certain point. Obviously, several commercial games do use IDs instead of pointers (for example the expansion to Oblivion, though that may be a discouraging example).

Many 'smart pointer' systems also implement a 'weak pointer' type. When an object is deleted (via the delete keyword, giving you property [2]), all 'weak pointers' to that object magically become NULL. This also gives you property [1], as if an object no longer exists, then it's pointers will be NULL.


Personally I use pointers and ID's at the same time - you can use an ID to retrieve an objects pointer value.
ID's are useful for serialisation and network replication, plus the linear ordering and generally small values of ID's provides better network packet compression than using unpredictably ranged pointer values as an ID.

Quote:Original post by Zahlman

Quote:Original post by dmatter
You're right, but you shouldn't be doing anything with the value in the integer (like testing for nullness). In order to use such a handle it needs to be cast back to a pointer type.

But then what do you need the cast for?

Do you mean 'why cast at all'? In other words are you highlighting that casting a pointer->integer->pointer seems entirely pointless? I'll answer on the assumption that you are...

The idea was to have some kind of simple type to represent a handle, the obvious choices were either an integer ID or a pointer. When considering all three implementations, of OGL, D3D9 and D3D10, I decided an integer handle type would be the most appropriate:

OpenGL: The API itself uses integer handles.
D3D9: Resources are volatile, their pointers could be stored in an array and an integer handle could be used to index them.
D3D10: Resources are not volatile, may as well cast their pointers to the handle-type rather than index them from an array - a trivial micro-optimisation.

In 2/3 implementations an integer handle seemed the most sensible option. In the D3D10 implementation an integer isn't the most natural handle type but I could safely get away with a cast.

It all worked flawlessly although the actual abstraction itself was botched; it's all gone by the way-side since anyway. My newer renderers are less 'C like' and more 'C++ like'.