4 ms·
Nice, but it's rather naive and through that - needlessly wasteful. It's C. Why on Earth you'd want to allocate a separate list node for each piece of data wh
by eps 11y ago
Nice, but it's rather naive and through that - needlessly wasteful.
It's C.
Why on Earth you'd want to allocate a separate list node for each piece of data when you can embed this node directly into the data and then use container_of or similar offsetof() derivative to get a pointer to the data by a pointer to a list item? Saves you at least sizeof(void*) per item and eliminates a chance of list_add ever failing among other things.
The same goes for custom allocators - why would you drag around pointers to malloc, calloc and free, when all you need is just a pointer to realloc?
This sort of thing. The code is nice, but it's not how one would write a container library after few years of hands-on C experience.
- seiji 11y agoallocate a separate list node for each piece of data So many programmers don't even consider "overhead" of data when writing things. But, most of the time it doesn't matter. Do you need a list of ten things? Great. Do whatever. Do you need a list of a billion things? Then you need to rethink everything from the bottom up. when all you need is just a pointer to realloc Wrong! https://github.com/Tarsnap/libcperciva/commit/cabe5fca76f6c38f872ea4a5967458e6f3bfe054 https://github.com/Tarsnap/libcperciva/commit/cabe5fca76f6c3...
- deleted 11y ago[deleted]
- catnaroek 11y ago> So many programmers don't even consider "overhead" of data when writing things. Because they're using managed languages where the amount of overhead per object can't be reduced to zero. And also because, in exchange for that overhead, they get other benefits, like compacting garbage collection. But you don't get this in C.
- eps 11y ago> Wrong! https://github.com/Tarsnap/libcperciva/commit/cabe5fca76f6c3.. https://github.com/Tarsnap/libcperciva/commit/cabe5fca76f6c3.... No, of course not "Wrong!" If a user of a library wants to supply their own allocator, they must provide a version of realloc that acts as free() for the (p,0) case. That's the semantics the library expects, observe them. Internally the lib may look at whether a custom realloc is set, and fallback to malloc/free if it's not.
- dllthomas 11y ago"Why on Earth you'd want to allocate a separate list node for each piece of data when you can embed this node directly into the data" It's a good approach when the items may need to be in several lists at once.
- junke 11y agoYou can certainly put the payload into multiple lists. From http://www.crashcourse.ca/introduction-linux-kernel-programming/intermission-lets-talk-about-linked-lists-and-containerof-free http://www.crashcourse.ca/introduction-linux-kernel-programm...: > More to the point, a payload is welcome to participate on several lists, but only after defining an internal list_head object for each list. In other words, unlike the payloads you're used to that contain only pure data and could (theoretically) be on an infinite number of lists at once, objects on kernel lists can be only on those lists for which they have an internal set of links. It's an interesting way to lock down what lists you're willing to be a member of.
- dllthomas 11y agoSorry, yes, rather the problem comes from a sufficiently dynamic set of list memberships.