I really like the iterative deepening approach to teaching/learning because it matches how I learn anyway. First the basics, then dive deeper and deeper. It also seems a good fit for learning something slowly or over a longer time.
Takeaway 0.1.2.1 C is a compiled programming language. No, it can also be interpreted.
True, you can say this about a lot of “compiled languages”, but all the C code I’ve run across is compiled. Yes, the author could have been more clear.
Takeaway 0.1.2.2 A correct C program is portable between different platforms. No, this is a point of view.
Portability isn’t a “point of view.” Your code either (builds and) runs or doesn’t (build and) run. There’s a lot of factors involved in portability, I’m not sure you can say, “This is portable” without actually trying it on your target platforms. There’s the libraries involved, compilers/linkers for specific platforms might not implement certain things correctly, system libraries for your platforms might cause issues, the program might exceed memory capacity of some platforms but not others, etc. There are things you can do to help portability, like not use compiler-specific language extensions, which I think is the author’s intent.
Takeaway 0.2.2.1 All identifiers in a program have to be declared. No, #ifdef ABC // check whether the identifier ABC is declared
True. ABC is an identifier, however, your example only checks whether ABC is an identifier declared as a macro name
I think “correct’ used here by the author with respect to the C language spec, since the following paragraph references language extensions.
“All identifiers” does not mean “all except macro …”
I agree with your point about identifiers. My point was that the example you provided as elaboration on your point (which is right in that ABC is considered an identifier in the #ifdef) has an incorrect comment. “// check whether the identifier ABC is declared” should be “// check whether the identifier ABC is declared as a macro name”.
EDIT: Your example proves a good point! I don’t want it sullied because the comment isn’t entirely correct.
I really dislike calling languages “compiled” and “interpreted”. It is only an implementation detail, and the fact that majority of implementations do one way or another doesn’t change anything. Yes, majority of C implementations do compile it, but you can also interpret it. Majority of Python implementations interpret it, but there are implementations that compile it(like Nuitka). It doesn’t matter how a language is implemented, it is not “compiled” or “interpreted” - the implementation is.
Just nitpicking, but technically a language’s specification can make a it “compiled” or “interpreted”, which is admittedly a rare case. Also, implementations can use some hybrid of interpretation and compilation, like a runtime or virtual machine.
Actual link to the book and not a blog post talking about the book: https://gforge.inria.fr/frs/download.php/latestfile/5298/ModernC.pdf
(PDF warning)
I really like the iterative deepening approach to teaching/learning because it matches how I learn anyway. First the basics, then dive deeper and deeper. It also seems a good fit for learning something slowly or over a longer time.
As far as I know, it’s made by the same person who created the musl libc, which is considered well written and clean.nvm.
No, musl libc was created by Rich Felker. Jens Gustedt is involved with WG14, the ISO C working group.
[Comment from banned user removed]
True, you can say this about a lot of “compiled languages”, but all the C code I’ve run across is compiled. Yes, the author could have been more clear.
Portability isn’t a “point of view.” Your code either (builds and) runs or doesn’t (build and) run. There’s a lot of factors involved in portability, I’m not sure you can say, “This is portable” without actually trying it on your target platforms. There’s the libraries involved, compilers/linkers for specific platforms might not implement certain things correctly, system libraries for your platforms might cause issues, the program might exceed memory capacity of some platforms but not others, etc. There are things you can do to help portability, like not use compiler-specific language extensions, which I think is the author’s intent.
True. ABC is an identifier, however, your example only checks whether ABC is an identifier declared as a macro name
Calling portability ‘correct’ is a point of view.
“All identifiers” does not mean “all except macro …”
I think “correct’ used here by the author with respect to the C language spec, since the following paragraph references language extensions.
I agree with your point about identifiers. My point was that the example you provided as elaboration on your point (which is right in that ABC is considered an identifier in the
#ifdef) has an incorrect comment. “// check whether the identifier ABC is declared” should be “// check whether the identifier ABC is declared as a macro name”. EDIT: Your example proves a good point! I don’t want it sullied because the comment isn’t entirely correct.I really dislike calling languages “compiled” and “interpreted”. It is only an implementation detail, and the fact that majority of implementations do one way or another doesn’t change anything. Yes, majority of C implementations do compile it, but you can also interpret it. Majority of Python implementations interpret it, but there are implementations that compile it(like Nuitka). It doesn’t matter how a language is implemented, it is not “compiled” or “interpreted” - the implementation is.
It’s interpreters all the way down. All compilation does is translate a program from one form to another.
Just nitpicking, but technically a language’s specification can make a it “compiled” or “interpreted”, which is admittedly a rare case. Also, implementations can use some hybrid of interpretation and compilation, like a runtime or virtual machine.