Earlier quoted context omitted.
For my tastes there is way too much whitespace and I usually only use multi-line comments to describe the high level algorithm for a full function. I prefer to pepper single-line comments which describe the sequence of events in a human-readable way. I've been C/C++ for about 25 years.
My taste is that function level comments describe the "what" and inline comments describe the "why". So at a function level the comments is giving a highlevel description to the reader as to the functionality contained, and at the line level comments exist only to say describe the programmers intentionality, why it was implemented this way rather than some other way. I have generally found (there are always exception…
Linus Torvalds' good taste argument for linked lists, explained
201–210 of 339 posts
Re: Linus Torvalds' good taste argument for linked lists, explained
#202I think what's missing in the mental model of the elegant solution is, that the IntList-pointer does not point to a complete list or an element of the list, but to a tail of some list (that might be the complete list). This explains why the head is not really a special case, as it points to the tail that is complete. And you can just exchange a tail. So I think the image with the blue boxes is misleading and it shoul…
The c code being weird is more of an implementation detail that shouldn’t be of much focus.
Re: Linus Torvalds' good taste argument for linked lists, explained
#2032013 - stop using linked lists: https://news.ycombinator.com/item?id=5751702
a) When your nodes can belong to multiple lists. You can't do this with arrays.
b) When you need fast removal from the middle of the list and you already have a pointer to the list node [2].
[1] In an intrusive linked list, the prev/next pointers are members of the payload node, as opposed to a "simple" linked list, in which the list nodes contain a pointer to the payload.
[2] This happens all the time in kernels. For example, you receive an interrupt and need to remove the corresponding task from the IDLE queue and append it to the RUNNING queue.
Re: Linus Torvalds' good taste argument for linked lists, explained
#204Earlier quoted context omitted.
I’m not a fan of everything Bukowski wrote, but I wouldn’t try to censor him so that little Jimmy could read it, and I liked the movie Barfly. Similarly, I’m not a fan of everything Linus wrote, but I wouldn’t enforce bad CS101 code on him so that little Jimmy could read it, and I like Linux.
Who is little Jimmy?
Adding "little" in front just stresses the fact that we are talking about a kid, so the references are about dumbing it down for kids.
Johnny is probably a bit more common than Jimmy, but I've seen both. See e.g. [1]
Re: Linus Torvalds' good taste argument for linked lists, explained
#205Earlier quoted context omitted.
What happens at the end of the list? Is next null? And if so, how do either of these methods behave?
This is a circular linked list, where the ->next pointer points back to the head of the list. It's helpful for iteration tasks, since you can always walk the full list when you get access to one node. In most cases you use a linked list like this, you don't care about the order of things, just that you can iterate over all items in the list.
Re: Linus Torvalds' good taste argument for linked lists, explained
#206Maybe slightly off topic, but.. I don't think this is really about taste. It's about "common ground" between programmers. If you've seen and used the second pattern many times before, it becomes part of your vocabulary. You're then able to express yourself more succinctly. It is then obviously a better solution to you. If you see another programmer use the same pattern, it is common ground between you, and you like i…
this is the big point. when coding alone I strongly prefer Linus's version. but it seems to cause friction and get called out whenever I use it in a group environment. so I don't. or I change it. the code itself isn't important. its about the functioning of the group, the velocity, and the ownership.
It isn't either/or. It can be all of the above, to varying degrees, that change over time.
Re: Linus Torvalds' good taste argument for linked lists, explained
#207I've been teaching CS101 for two decades. I've never shown (nor seen another instructor show) a two pointer implementation for list traversal, except perhaps as an example of bad practice (probably by someone who doesn't understand the syntactic sugar of the -> operator). "Every pointer to node is a list, including the trivial case of a null pointer being an empty list" is the way I was taught in CS101 in the early 8…
So Say We All.
Re: Linus Torvalds' good taste argument for linked lists, explained
#208Re: Linus Torvalds' good taste argument for linked lists, explained
#209Earlier quoted context omitted.
I can't help but notice how this code, as well as in the article, there's no checks for a) a NULL list or b) that the item is in fact part of the list. A simple fix is: while (!!walk && walk != entry) { prev = walk; walk = walk->next; } or while (!!indirect && !!(*indirect) && (*indirect) != entry) indirect = &(*indirect)->next; ...because without those checks it's pretty easy to see where you'll crash... but by putt…
I believe the implicit requirement is that the item is known to exist within the list. With that requirement in place the extra guards aren't requisite (they're implicit) and in kernel code this probably offers a performance edge and is a reasonable requirement. Either having an implementation that has an extra check once at the end of the list, or that verifies the presence of the item and passes that node through t…
Re: Linus Torvalds' good taste argument for linked lists, explained
#210I've been teaching CS101 for two decades. I've never shown (nor seen another instructor show) a two pointer implementation for list traversal, except perhaps as an example of bad practice (probably by someone who doesn't understand the syntactic sugar of the -> operator). "Every pointer to node is a list, including the trivial case of a null pointer being an empty list" is the way I was taught in CS101 in the early 8…
Agreed.
> It also allows you to avoid warts like `p = &(p)->next;`
Does it? Isn't having `p = &(p)->next;` in the while loop necessary?
> at the modest cost of needing `p=remove(p,t)` instead of `remove(p,t)`.
I may disagree since an API is used many more times than the API function is written.