Re:Zig's new LinkedList API (it's time to learn fieldParentPtr)
by cheezebubba on Monday April 14, 2025 @12:02PM
(#43682780)
Thanks. I still don't understand where the bits live that tell you which type T is for a given node.
Is this something like "list starts with type A, and that will tell you if the next node is type A or B"?
Is there a way to stuff those bits in with the node somehow so you always know the type you expect back?
Re:Zig's new LinkedList API (it's time to learn fieldParentPtr)
by throwawaymaths on Monday April 14, 2025 @12:10PM
(#43682862)
> Thanks. I still don't understand where the bits live that tell you which type T is for a given node.
Yup. You'd have to set that up yourself. It could be anywhere. It could be in a separate array, it could be in the previous node-data, etc.
you wouldn't put it in the Node (capital N) datastructure though, that is privileged.
Personally, I would say doing something like this is "bad idea bears" unless you are absolutely certain you need it and you should explore using, say, data payload type with a union field instead, if possible (though know that that comes with a potential memory penalty)
Re:Zig's new LinkedList API (it's time to learn fieldParentPtr)
by cheezebubba on Monday April 14, 2025 @12:30PM
(#43683099)
Aha Thanks!
So you could have a mixed-type linked list, and at the callsite zig can at compile-time back out the parent type. There obviously needs to be outside logic (and an outside mechanism to track) this with branches for each type that you could be putting into the linked list. And yes, this is more than a little bit type-unsafe because of the potential for type erasure.
You could probably pretty trivially write a typesafe wrapper for this, as suggested in one of the comments here.