Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: [Solved] Need some help getting to my feet Date: Fri, 27 Apr 2018 10:36:28 -0700 Organization: None to speak of Lines: 85 Message-ID: References: <87o9i7ovsc.fsf@bsb.me.uk> <752bbd42-4649-4537-bb9a-01ecc72d3b0c@googlegroups.com> <87in8etgms.fsf@bsb.me.uk> <4330b8c3-bcd0-4213-a276-a0c4fb25c810@googlegroups.com> <87y3h9sha3.fsf@bsb.me.uk> <5da45b9b-6b02-4e92-ac51-1abf1e8fe4c4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="cc0e2a6c7d0567601a378dba59302632"; logging-data="26564"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+s1/YPDokUPMKWG9a+RYrT" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:I9AGxVw5rHude4/qq/PniCp9VgA= sha1:8t1XdfNpn4eU1ClpH9r+lBNSv9M= Xref: csiph.com comp.lang.c:129865 Malcolm McLean writes: > On Friday, April 27, 2018 at 12:02:38 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean writes: >> >> > On Thursday, April 26, 2018 at 11:19:03 AM UTC+1, Ben Bacarisse wrote: >> >> Malcolm McLean writes: >> >> >> >> What do you believe this shows? Do you think the errors here make >> >> things simpler? >> >> >> > The tutorial was obviously written when everyone used DOS. Except a >> > few Unix types in academic or high end professional computing who >> > mostly knew C anyway. >> >> The reason for the error is beside the point. I wondered why you >> thought making it simplified anything. >> > The header file itself was called STDIO.H on DOS systems, which didn't > allow lower case filenames at the time. But the compiler accepted > stdio.h in lower case. So that's potentially confusing. Schildt is > telling his readers that they might see upper case, whilst telling > them to prefer lower case. Which is correct enough. He could simply have told them to use lower case for standard headers. There is no good reason to even consider writing `#include `. Schildt stated as "the traditional method" something that should be treated, for simplicity, as an absolute rule. If he wanted to abandon the simplification you advocate and discuss the fact that the file (which users needn't even be aware of) is named "STDIO.H", he could have gotten into that, and explained that what appears between the <> isn't simply a file name. But all a beginning programmer needs to know is that you need to write #include at the top of the source file. C identifiers and keywords are case-sensitive and usually lowercase; the fact that header names follow the same pattern shouldn't confuse anyone. You're grasping at straws. >> > The books were very popular, and part of the reason is the informal style, >> > avoiding over-qualification or the premature use of technical >> > terms. >> >> But this example introduces more technical terms whose only purpose >> appears to make a mistake. Surely it's just better to leave out any >> talk about letter cases. >> >> And I find the part about the semi-colon and keywords defining >> statements to be excessively technical without being particularly >> clear. >> > He's just explained the anatomy of a C statement. It ends in a semi-colon. > It's not always clear to a beginner where semicolons go and where > they don't. They don't terminate #include directives. That of course > is because these are preprocessing directives rather than actual > C statements. But he's withholding some of the full truth there for > pedagogical purposes. That's why the writing is clear and engaging. C statements end in semicolons (except that compound statements don't). So do declarations. So do the first two clauses of a for statement. So do struct member definitions, due to a distinct syntax rule separate from the one for declarations. #include directives don't end in a semicolon because that's the syntax. The underlying reason, which Schildt could have gone into if he had wanted to, is that preprocessor directives are strictly line-oriented, so there's no need for semicolons as a separator. His claim that it's because "it is an instruction to the C compiler itself" is nonsense. Everything in a C source file is an instruction to the C compiler. And again, the *simple* way to explain it would be just to say that a #include directive does not end in a semicolon. More generally, preprocessor directives are line-oriented, begin with #, and do not include semicolons as part of their syntax. His explanation is both more complicated and wrong. But his writing is clear end engaging, so that's ok. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"