3 ms·

sys/queue.h has some really useful list macros. It has FOREACH, HEAD, TAIL, INSERT_*, the works. http://freebsd.active-venture.com/FreeBSD-srctree/newsrc/sys/

sys/queue.h has some really useful list macros. It has FOREACH, HEAD, TAIL, INSERT_*, the works. http://freebsd.active-venture.com/FreeBSD-srctree/newsrc/sys/queue.h.html http://freebsd.active-venture.com/FreeBSD-srctree/newsrc/sys...

demallien 16y ago
And may it rot in hell for forcing you to add fields into every struct that might find itself in a list at some point in it's life. May it doubly rot in hell for forcing you to add those fields for every list that the object might be a part of. May it triply rot in hell for using unsightly macros that are impossible to debug, particularly when working in an embedded environment. queue.h - just say no.
- rw2- 16y ago
  so, what's the alternative? do you have a nice typesafe library for external lists?
  - demallien 16y ago
    If I have to throw typesafety onto the sacrificial bonfire to avoid queue.h, then I do it with a light heart. I really don't see any value in it. You have two possible situations: 1) The list contains only items of one type - in this case you already know what the type of all objects in the list is - it's a list of widgets, so all items are of type Widget. Whilst queue.h will give you a compiler warning if ever you try to put a File into your widget list, is that every really likely to happen in real life??? 2) You have a list of mixed-type objects. In that case you need code to identify at runtime what the type of the object was anyhow, so type safety gets you nothing in that case either. So, considering how little you get back for the decidely annoying problems of macros and polluted data structures, I really have no hesitation in counselling the avoidance of queue.h. In answer to your question, no, I don't have a nice typesafe library. But I do have a nice non-typesafe library.
  - torpor 16y ago
    list.h from the Linux kernel.

demallien 16y ago

And may it rot in hell for forcing you to add fields into every struct that might find itself in a list at some point in it's life. May it doubly rot in hell for forcing you to add those fields for every list that the object might be a part of. May it triply rot in hell for using unsightly macros that are impossible to debug, particularly when working in an embedded environment. queue.h - just say no.

rw2- 16y ago
so, what's the alternative? do you have a nice typesafe library for external lists?
- demallien 16y ago
  If I have to throw typesafety onto the sacrificial bonfire to avoid queue.h, then I do it with a light heart. I really don't see any value in it. You have two possible situations: 1) The list contains only items of one type - in this case you already know what the type of all objects in the list is - it's a list of widgets, so all items are of type Widget. Whilst queue.h will give you a compiler warning if ever you try to put a File into your widget list, is that every really likely to happen in real life??? 2) You have a list of mixed-type objects. In that case you need code to identify at runtime what the type of the object was anyhow, so type safety gets you nothing in that case either. So, considering how little you get back for the decidely annoying problems of macros and polluted data structures, I really have no hesitation in counselling the avoidance of queue.h. In answer to your question, no, I don't have a nice typesafe library. But I do have a nice non-typesafe library.
- torpor 16y ago
  list.h from the Linux kernel.