This is easy to do with the proper support for monomorphized generics, see C++'s std::list. It is awkward in C, where the implementation has to be macro-generated.
Fairly pleasant in Zig, through abuse of @fieldParentPointer and a pinch of comptime.
It was a little nicer in the `usingnamespace` days. So it goes.
The elements can be allocated on the heap, on the stack, in a global array (like "initholes" in the article), in a special arena, etc.
An "etc" worth mentioning specifically is a memory pool: they're useful for any same-sized struct which gets recycled a lot, but for linked lists there are further advantages. You don't have to cast the object to bytes and declare a link pointer, since it already has one: not really an advantage, casting is free, but: if you can arrange to give both sides of the list back, then recycling can be done on a per-list level by prepending the whole thing to the freelist.
Comments
Fairly pleasant in Zig, through abuse of @fieldParentPointer and a pinch of comptime.
https://github.com/mnemnion/zelda
It was a little nicer in the `usingnamespace` days. So it goes.
An "etc" worth mentioning specifically is a memory pool: they're useful for any same-sized struct which gets recycled a lot, but for linked lists there are further advantages. You don't have to cast the object to bytes and declare a link pointer, since it already has one: not really an advantage, casting is free, but: if you can arrange to give both sides of the list back, then recycling can be done on a per-list level by prepending the whole thing to the freelist.