Handles instead of Pointers

HandleMap or HashMaps?

  1. A handle_map_static.

    • A handle is nothing more than an index while using a sparse array.

    • Super lightweight.

  2. A map[int]Listener , where each int is a "handle."

    • The int could be a random number, maybe obtained via Unix time.

  • What’s the difference ?

    • HandleMap:

      • Works really well when the object being stored is a pointer. It’s far safer.

      • Handle somehow requires it to also be stored inside the Listener.

    • HashMap:

      • Can be intrinsically lighter on memory.

        • Does not require the object stored in the HandleMap to contain a handle.

      • No need to worry about static memory limitations.

        • The HashMap expands automatically.

  • Which to choose :

    • HandleMap for storing pointers; always.

    • HashMap for non-pointers.

Articles

  • Handles are the better pointers .

    • The article is very good.

    • It doesn’t show any code, but all concepts are explained and the advantages of the approach are clearly presented.

  • The Ownership Semantic Flaw .

    • Important conclusion about OOP and Ownership Semantics (OS):

      • In general, most hard problems cannot  be solved at compile time; because of this, adding more and more concepts to the type system of the language will not help without adding extra costs. This does not mean ownership semantics are bad but that they are not a solution for many problems in that domain.

      • A lot of the problems related to responsibility are better solved with forms of “subsystems” within programs which handle groups of “things” and give out handles  to the “thing” instead of a direct reference.

      • This is related to the approach many people already use to bypass the borrow checker by using indices/handles.

      • Handles can contain a lot more information than a single number. A common approach is to store a generation number alongside the index in the handle. If a generation has expired, but the handle is used, the subsystem can return a dummy sentinel value and report an error.

      • Other approaches aim to reduce the need for ownership responsibility in the first place. By keeping data structures POD , trivially copyable, and with a useful zero value, you can rethink the problem and simplify code. This places more emphasis on the data and algorithms themselves rather than the relationships between objects and types.

    • Final conclusion of the article:

      • The main argument is to demonstrate how OS and OOP both result in a "(linear) value hierarchy of behavior, where the values act as agents."

      • Ownership semantics can be a useful tool for certain problems, but due to their underlying linear logic, they cannot  be used to express non-linear  problems, which leads people to try to bypass the concept entirely.

    • (2025-07-03)

      • I found the article very interesting.

      • I found it interesting how the use of handles was mentioned as something that could solve the problem and how it's used in Rust to work around linearity issues.

      • I don’t yet know the counterarguments to this Rust linearity problem, but if it’s really solved through some kind of handle trick, then it does seem like Rust hasn’t solved an important problem — it just complicates things unnecessarily.

Libraries

  • handle-map-odin .

    • Very interesting and quite simple as well.

    • From what I saw through ChatGPT, its code follows a very classical handle system structure.

    • Check the README to understand the best usage recommendations, considering virtual memory limitations for the web.

    • Questions :

Usage examples

  • The sokol-gfx API is an example of a C API that uses handles instead of pointers for rendering resource objects (buffers, images, shaders, …):

  • The Oryol Gfx module is a similar 3D API wrapper, but written in C++:

  • The Oryol Animation extension module is a character animation system that keeps all its data in arrays: