81–87 of 87 posts
Earlier quoted context omitted.
Yes, in C you must use 'void' to indicate that the function takes no arguments. (This is deprecated in C++ in favor to an empty argument list - which breaks backward compatibility with C).
What happens if I extern a C function with no "void" then? Do I get a variadic in C++?
Earlier quoted context omitted.
I don't know, but I would dearly love to use a compiler that does that.
> I don't know, but I would dearly love to use a compiler that does that. Well you're in luck, since gcc -Werror when used with many of its -W flags will do precisely that. You guys should read the minutes of committee discussions and position papers. "undefined behavior" is not something introduced to make programmers' lives hard! Also look at IEEE734 which does define things to an incredible degree -- it's extremel…
"You may have thought you were checking for overflow here, but technically speaking the result of that operation could be undefined, therefore this code could do literally anything, or nothing. So I'll just remove it all. Congratulations, now it runs faster!"
I honestly hadn't realized that was a controversial view. Doesn't almost everyone dislike that? Are there a lot of C programmers who are happy to accept that risk in exchange for slightly better optimization?
Earlier quoted context omitted.
> I don't know, but I would dearly love to use a compiler that does that. Well you're in luck, since gcc -Werror when used with many of its -W flags will do precisely that. You guys should read the minutes of committee discussions and position papers. "undefined behavior" is not something introduced to make programmers' lives hard! Also look at IEEE734 which does define things to an incredible degree -- it's extremel…
> Well you're in luck, since gcc -Werror when used with many of its -W flags will do precisely that. That's not lucky; I'd argue it's the opposite. An ecosystem built around compilers that default to not using -Werror (or rather: `-Werror=pedantic -pedantic-errors`) is an ecosystem that encourages people to write code that relies on the optimizations compilers make in response to undefined behavior. Which, undoubtedl…
Earlier quoted context omitted.
Imagine all memory is a big array. A pointer is just an index into that array. A pointer dereference is like accessing something at an array index. A pointer to a pointer is array index to a location where you'll find another array index.
I understand pointers conceptually. It's the syntax (in C specifically) that is giving me trouble. I am fine with pointers in ASM.
It's old-fashioned but I assume (maybe others can correct me) the latest edition is up to date enough that it won't teach you any outright bad habits.
Earlier quoted context omitted.
I understand pointers conceptually. It's the syntax (in C specifically) that is giving me trouble. I am fine with pointers in ASM.
Hmm, it's been a long time since I read it, but this sounds like something that good old K&R probably does well. It's famously short and well-written. It's old-fashioned but I assume (maybe others can correct me) the latest edition is up to date enough that it won't teach you any outright bad habits.
Earlier quoted context omitted.
> It really seems like the C standard maintainers and compiler vendors should just get together and sort that whole mess [Undefined behavior] out. Why do you think there is undefined behavior? Because committee members are lazy? Not every machine is a C machine (PDP-11). I used to program machines with bytes that could range from 1-36 bits (these are older than the PDP-7/PDP-11 that C was designed for). A joy to prog…
I realize it's there for a reason -- as I understand it, to avoid constraining compilers into generating unnecessarily awkward code for unlikely edge cases. And that fits with one of C's main advantages, being fast and lightweight. But in the last few years I've read many, many articles about problems that crop up when optimizing C compilers do weird things to reasonable-looking code, citing "undefined behavior" as a…
If the behaviour is undefined then the code is broken. Programmers need to learn the language instead of putting together hail mary code expecting it to somehow work in spite of the language specifically telling them that they should not expect any defined behavior out of it.
People who whine about undefined behavior are like kids who insist in jamming their fingers in a electric socket and whine when they get a shock.
Earlier quoted context omitted.
I realize it's there for a reason -- as I understand it, to avoid constraining compilers into generating unnecessarily awkward code for unlikely edge cases. And that fits with one of C's main advantages, being fast and lightweight. But in the last few years I've read many, many articles about problems that crop up when optimizing C compilers do weird things to reasonable-looking code, citing "undefined behavior" as a…
> do weird things to reasonable-looking code, citing "undefined behavior" as an excuse. If the behaviour is undefined then the code is broken. Programmers need to learn the language instead of putting together hail mary code expecting it to somehow work in spite of the language specifically telling them that they should not expect any defined behavior out of it. People who whine about undefined behavior are like kids…