| ▲ | samatman 6 hours ago | |
> 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. https://github.com/mnemnion/zelda 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. | ||