Why is this important?
Humans should think of sizeof() as a function, says Linus Torvalds
101–110 of 140 posts
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#102Earlier quoted context omitted.
Except sizeof is a compile-time operation, not runtime. If sizeof were a function, int *foo = malloc(sizeof(*foo)); would make no sense.
Compile-time functions are a thing. Not in C, but in other languages, including C++. This all comes down to what you think "function" means. If you're living in a C bubble, of course sizeof isn't a function. If you have a wider mapping (!) for the word, then it is a kind of function.
If you think everything called a "function", in every context, is the same thing, you are going to have a very bad day.
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#103Yes, return can be a function. Torvalds hasn't heard of continuations, obviously, where we "return" from a function by invoking a continuation.
We can justify writing return (expr); using the same arguments that justify the sizeof (expr) convention.
The thing is that in C, return isn't a function; there are no continuations.
Similarly, sizeof is an operator, which doesn't reduce its argument expression to a value.
If we are going to make coding conventions based on pretending that C is a different language in which sizeof is a function, then pretending return is a function is also fair game.
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#104Earlier quoted context omitted.
I would imagine once you get used to him and thicken your skin up a bit, it's no big deal. Hell, a little salty language and telling people they're being idiots when they are being idiots is not a bad thing. The best machinists and millwrights I've worked with were like that, and it was a good thing - you don't have time to ask politely when there are steal beams or a two-ton electric motor swinging towards you. C ca…
He literally says that those who disagree with his code style should be shot. That's completely unacceptable language to use and makes him sound like he hasn't mastered English. I'm not sure anyone should take c-language style tips from such a boor.
Most systems programmers I known share similar views.
The rational is that you should only be working on systems-level code if you have an exceptional understanding of computers, the code base, and the repercussions of changes. If your understanding of multithreading isn't flawless then you should not be working on the OS scheduler, at all. And for a programmer working at this level to not recognize the importance of code clarity is to undermine the responsibility that goes with it.
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#105Earlier quoted context omitted.
In Go, however, go fmt will remove the unnecessary parentheses. I was very annoyed at first, when I saw this, but I got used to it.
Does it generally do this in expressions, based on operator precedence, or is it limited to the outer parentheses on selected statements?
I am not an expert, but I think it only removes the outermost ones. The major task of the tools is indentation and placement of curly braces.
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#106> "return()" is in no way a function. Ah, but in Haskell, `return` is a function, though it shares only a few similarities with with its counterpart in C-like languages. However, when using continuations or a continuation passing style, the continuation is a function that behaves almost exactly like traditional return when called! (define (multiply x y return) (return (* x y)))
Was there something factually incorrect in my comment?
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#107Earlier quoted context omitted.
for, if, and while without curly braces for single statement blocks are easily one of the worst things about C. It bites you in the ass every time. The balance between its utility and its capacity to cause bugs is so one sided, I don't understand why it's even taught to beginners. If you are teaching a new programmer that saving keystrokes is important, you're on the fast track to creating a shitty programmer.
That's pretty severe. Written with spacing, its really pretty clear what is meant by if (condition) Foo(x) Braces are, in my opinion, an unfortunate necessity in some cases. They are a much larger cause of error than NOT using them ever could be. An ideal IDE would make blocking visible (background tone change etc), and braces could be emitted automatically by the IDE without ever cluttering up the code shown to the…
But tying everyone to a single IDE is never going to happen. The language is out there. It's going to stay backward compatible forever.
How could the presence of braces cause a worse error than no braces? Code compiles when you completely omit braces but put more than one statement underneath. The error is logical, not syntactical.
But if you have an open brace without a matching close brace, that's a compile error. What other error are you referring to?
How can you know that you won't add more statements to the block? Why have a special case at all? For me it's just become muscle memory to add the braces. It's a risk with exactly zero upside to omit braces.
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#108Yes, return can be a function. Torvalds hasn't heard of continuations, obviously, where we "return" from a function by invoking a continuation. We can justify writing return (expr); using the same arguments that justify the sizeof (expr) convention. The thing is that in C , return isn't a function; there are no continuations. Similarly, sizeof is an operator, which doesn't reduce its argument expression to a value. I…
He is talking about C. Continuations are irrelevant.
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#109> "return()" is in no way a function. Ah, but in Haskell, `return` is a function, though it shares only a few similarities with with its counterpart in C-like languages. However, when using continuations or a continuation passing style, the continuation is a function that behaves almost exactly like traditional return when called! (define (multiply x y return) (return (* x y)))
Was there something factually incorrect in my comment?
Was there something relevant in your comment?
Re: Humans should think of sizeof() as a function, says Linus Torvalds
#110Yes, return can be a function. Torvalds hasn't heard of continuations, obviously, where we "return" from a function by invoking a continuation. We can justify writing return (expr); using the same arguments that justify the sizeof (expr) convention. The thing is that in C , return isn't a function; there are no continuations. Similarly, sizeof is an operator, which doesn't reduce its argument expression to a value. I…
Why shouldn't return be considered a function?