I don't really know anything about the linux Kernel, nor about the competence of Torvalds. He might be an excellent programmer(and he's of course a pretty successful one), but personally he reminds me of the kind of person who's concetrating in low-level constructs in order to save a couple of cycles, while at the same time is completely oblivious to the fact that he loses hundreds of them by implementing sub-par or just plain wrong algorithms.

It's funny that, in that conversation, someone trying to defend Torvalds mentions the pc demoscene, and how those "hard-core" programmers use assembly to squeeze those impressive demos in only 64KB. He couldn't be more wrong. Farbrausch clearly state in their "readme" that .the.product and .kkrieger(the 96KB FPS) are mainly written in C++ save from some tiny assembly pieces where it was actually needed. They didn't achieve this huge compression by saving one byte here and one cycle there. They did it by radically altering their algorithms in a high conceptual level. Torvalds, OTOH, pretty much states that him and the concept of "high-level" are not in speaking terms.

Ironically, the arguments he's using to bash C++ are pretty much the arguments many C++ fans use to bash the truly high-level languages. Funny that.

Quote:What is the right tool? It really depends. IMHO, it's not about what makes the code really maintainable, nor is it about how quickly I can write something. It's about the language I know best for meeting my requirements. If it's not a hobbyist program that I'm working on, it's about whatever tool that will pay my bills. I don't view it as what is the right (correct) tool, but what is the better of the tools at my disposel.

I would have to agree with this, especially with the part 'whatever pays the bills'...

About the goto's:

Actually while converting C++ code to C, there's a situation:

In C there are no destructors, so whenever leaving a function you need to do the cleanup yourself first. I had a C++ function, that, on each error, does "return". Now I need to replace each return by "cleanup, return".

This is VERY tempting to instead put the cleanup at the end of the function, with a label in front called "error_cleanup:", and replace each "return" by "goto error_cleanup;".

Is the above use of goto justified? Making an extra function and giving all the things that have to be cleaned up as parameters seems not a good idea, lots of parameters and code duplication in that case.

EDIT: I managed to make all the C code work without goto's now by moving stuff around :)

[Edited by - Lode on January 8, 2008 3:02:14 AM]

Quote:Original post by Lode
About the goto's:

Actually while converting C++ code to C, there's a situation:

In C there are no destructors, so whenever leaving a function you need to do the cleanup yourself first. I had a C++ function, that, on each error, does "return". Now I need to replace each return by "cleanup, return".

This is VERY tempting to instead put the cleanup at the end of the function, with a label in front called "error_cleanup:", and replace each "return" by "goto error_cleanup;".

Is the above use of goto justified? Making an extra function and giving all the things that have to be cleaned up as parameters seems not a good idea, lots of parameters and code duplication in that case.

take a peek at the linux kernel sources... in most places, you'll see exactly this mechanism (and since several people use it in several places, they can't be all wrong about it :D)... it's very usefull to do cleanup like this in C, if you need to add "one more thing to clean" to the function, you just add it in the "error_cleanup:" part.

Quote:Original post by cobrutake a peek at the linux kernel sources... in most places, you'll see exactly this mechanism (and since several people use it in several places, they can't be all wrong about it :D)... it's very usefull to do cleanup like this in C, if you need to add "one more thing to clean" to the function, you just add it in the "error_cleanup:" part.

I took a peak in the linux kernel source file linked to higher in the thread (exit.c). A lot of the goto's were used to make a sort of for or while loop, e.g.:

repeat:/*stuff*/if(....) goto repeat;

IMHO, such usage of goto is just a way of saying "fuck you all people who say goto's are evil, I use them to create my loops!", or in other words just totally ignoring everyone in favor of own style.

But then again, the file is from 1992! That's what I'd call legacy code.

Quote:Original post by Lode
"fuck you all people who say goto's are evil, I use them to create my loops!"

ROFLMAO! That would make a great signature! LOL!

If you ask me, kernel source is far from being the worst code I've seen in my life. Great effor has been put into writing comments and seems pretty readable.

Anyway lets not forget that Torvalds only wrote 2% of it.

Quote:Original post by Spoonbender
If you want to argue that using goto's like this is a good idea, you'll need better arguments than "lots of people do it". It might be true, but it doesn't really change whether or not it's a good practice.

That's only part of the argument (and considering usage is not entirely foolish. Certainly if nobody used it that would be a strong suggestion that it was known to be bad). What's your suggested method of doing mandatory clean-up before return in a function in C? Remember that destructors and RAII are unavailable. I'll argue that using if statements is worse because it doesn't scale (if you have more than a few possible error exits the code for the most common case will be indented far to the right). If you intend to make a function to handle clean-up instead of using a goto:
1. You add extra verboseness for no gain other than satisfying yourself that you don't use gotos.
2. Every time you add a new entity that needs to be cleaned up, you need to add an extra argument to the clean up function, and then search and replace all the calls to the function to call it with the new entity.
3. It's also probably avoided because people are worried about pushing stuff on the stack unnecessarily. However, this doesn't matter with modern compilers, which is why I put it last.


Of course, using goto because you don't know what a do-while loop is (which appears to be the source of a goto mentioned above) is silly. The compiler is there for a reason. It's important to remember that the purpose of programming languages is to save thinking, and to save typing. (Everything that can be written in a high level language can in principle be written directly in byte-codes, but not necessarily in your life time.)