Handles are the better pointers (2018)

This article reminds me (on the surface, this is deeper than my experience) of how the recent Goose language orients things.

I never worked with it but I seem to recall the old original Mac API's (Pascal based) used "handles" a lot to solve the issue of being able for the system to move allocations and memory out from under a program without it knowing, as a "pointer to pointer to <thing>". I was poring over those manuals in ~1988/1989 with visions of being a full-time Mac developer in my head.

▲

throwitaway222 an hour ago | parent | prev | next [-]

I remember back in the day in Windows C++ programming everything was a HANDLE memory is probably not serving me, but they were all really just void* renamed. And you use them with various win32 functions I guess to keep things straight. I don't miss those days.

	▲	delta_p_delta_x 5 minutes ago \| parent \| next [-]
		> but they were all really just void* renamed The good thing is that all of these can and have been quite neatly put into RAII[1] or some memory arena with custom deleters which use the Win32 functions. One could manually `delete` those handles, but there be dragons. Vulkan does something similar; everything is a VkSomething handle. They may just be pointers directly exposed by the driver, but even so, users are explicitly supposed to use vkDeleteSomething functions to delete them. [1]: https://github.com/microsoft/wil
	▲	andrewshadura 19 minutes ago \| parent \| prev [-]
		Famously Win16 API required locking memory allocations to be able to access them by a pointer. Unlocked allocations could be moved by the OS.

▲

Surac 16 minutes ago | parent | prev | next [-]

my API always use handels, not because i design them that way, but in every iteration they get more and more handles

▲

PaulHoule 2 hours ago | parent | prev [-]

A nice analysis of large-scale programming techniques that go beyond the novice version of "OO Sux" to the almost secret

https://en.wikipedia.org/wiki/AoS_and_SoA

and why game engines use entity-component systems, analytical databases are column-oriented, etc. That is, the classical organization of "objects" as structures has a lot of overhead when you're doing heavy work. For instance java reifies objects with a big header, a monitor lock, and other stuff that really adds up if you, say, are writing a chess engine and need to maintain transposition tables. And even if you are in C++ and there is a lot less overhead, AoS still has bad mechanical sympathy compared to SoA.

	▲	mac3n an hour ago \| parent [-]
		see Jovial language (https://news.ycombinator.com/item?id=27390796) SERIAL and PARALLEL tables.