simply good use of pointers-to-pointers etc. For example, I've seen too many people who delete a singly-linked list entry by keeping track of the "prev" entry, and then to delete the entry, doing something like
if (prev) prev->next = entry->next; else list_head = entry->next;
and whenever I see code like that, I just go "This person doesn't understand pointers". And it's sadly quite common.
People who understand pointers just use a "pointer to the entry pointer", and initialize that with the address of the list_head. And then as they traverse the list, they can remove the entry without using any conditionals, by just doing a "*pp = entry->next".
I'm going to have to disgree with Linus on that one. When I'm coding in a mixed group of people that includes old farts and interns and the performance isn't that critical, I'll do the former over the latter to insure that everyone in the group will understand it easily and will have less chance of breaking it if they change it. It can mean the difference between code that is robust and code that is fragile when it's being worked on, not just when it's running.
I believe that his pointer example is more a matter of personal style. I can easily see how doing away with the conditions will make for more efficient code, but in many cases, the preference he cites might also make the code a little more obfuscated. However, even that's nothing that a single-line comment wouldn't fix, making sure that whoever is reading the code fully realizes the intent behind it. I think perfectly valid arguments can be made for doing it either way.
I'm definitely a big fan of readability in code. Of course you have to know your intended audience. People reading kernel code are not the same audience as, I don't know, people writing a financial application in a high level language.
With the work I do I am able to favour readability over efficiency (then optimize if required.. no premature optimization). It makes maintenance so much easier (and let's face it, code spends most of its life being maintained). Code is already way harder to read than write a
I never said Linus was wrong. In fact I was agreeing it is correct in the kernel. A kernel dev would have no problem reading and understanding his example. Your average joe coder might stumble over it.
This is simply a smaller-scale of the same kind of improvement that object-oriented is.
What? That doesn't make any sense in the context of replying to my comment.
Average Joe coder must be educated, not kept in the darkness.
No. Not really.
Not all developers need to be able to read advanced pointer usage and tricks for the sake of tricks is stupid. There must be a measurable performance difference or it has to be easily readable by the group developing. If it isn't easily readable and there is no performance justification then education isn't the issue, it's developer ego, "Well I can read it."
Yeah, good for you. But I don't care about that. I care about whoever ends up having to maintain your difficult to read code. Prematu
Won't CPU branch prediction make the if based version as fast as the pointer to pointer version? If you have a thousand element list, then there's a only 1 in a thousand chance that you're deleting the first element all the other times you head down the other side of the conditional.
Not So Fast On The Pointers (Score:4, Interesting)
simply good use of pointers-to-pointers etc. For example, I've seen too many people who delete a singly-linked list entry by keeping track of the "prev" entry, and then to delete the entry, doing something like
if (prev)
prev->next = entry->next;
else
list_head = entry->next;
and whenever I see code like that, I just go "This person doesn't understand pointers". And it's sadly quite common.
People who understand pointers just use a "pointer to the entry pointer", and initialize that with the address of the list_head. And then as they traverse the list, they can remove the entry without using any conditionals, by just doing a "*pp = entry->next".
I'm going to have to disgree with Linus on that one. When I'm coding in a mixed group of people that includes old farts and interns and the performance isn't that critical, I'll do the former over the latter to insure that everyone in the group will understand it easily and will have less chance of breaking it if they change it. It can mean the difference between code that is robust and code that is fragile when it's being worked on, not just when it's running.
Re: (Score:5, Interesting)
I believe that his pointer example is more a matter of personal style. I can easily see how doing away with the conditions will make for more efficient code, but in many cases, the preference he cites might also make the code a little more obfuscated. However, even that's nothing that a single-line comment wouldn't fix, making sure that whoever is reading the code fully realizes the intent behind it. I think perfectly valid arguments can be made for doing it either way.
Personally, I would classify thi
Re: (Score:2)
With the work I do I am able to favour readability over efficiency (then optimize if required.. no premature optimization). It makes maintenance so much easier (and let's face it, code spends most of its life being maintained). Code is already way harder to read than write a
Re: (Score:0)
Sorry, but I think Linus is right here. This is simply a smaller-scale of the same kind of improvement that object-oriented is.
Re:Not So Fast On The Pointers (Score:2)
Sorry, but I think Linus is right here.
I never said Linus was wrong. In fact I was agreeing it is correct in the kernel. A kernel dev would have no problem reading and understanding his example. Your average joe coder might stumble over it.
This is simply a smaller-scale of the same kind of improvement that object-oriented is.
What? That doesn't make any sense in the context of replying to my comment.
Re: (Score:2)
Average Joe coder must be educated, not kept in the darkness.
No. Not really.
Not all developers need to be able to read advanced pointer usage and tricks for the sake of tricks is stupid. There must be a measurable performance difference or it has to be easily readable by the group developing. If it isn't easily readable and there is no performance justification then education isn't the issue, it's developer ego, "Well I can read it."
Yeah, good for you. But I don't care about that. I care about whoever ends up having to maintain your difficult to read code. Prematu
Re: (Score:1)
Best sig of the thread: (Score:2)
I nominate yours as the best sig of all this thread.