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: The case AGAINST C Date: Sun, 06 May 2018 13:38:48 -0700 Organization: None to speak of Lines: 82 Message-ID: References: <0wXGC.68476$ny5.58646@fx17.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="f99c42e1138a8c73b9677b033d51f90e"; logging-data="18428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Y9IFsEMpW0rc84xCRJxh+" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:pLsQF01EzIJsBUuofh5d8yTg0go= sha1:l2RsFKlzUkZ5lbqttustjCvVTkM= Xref: csiph.com comp.lang.c:130273 bartc writes: > On 06/05/2018 16:01, David Brown wrote: >> On 04/05/18 22:56, bartc wrote: >>> where hello.h contains: >>> >>> printf("Hello World!\n"); >>> >>> and is placed where the compiler can find it, then it compiles a >>> normal hello world program. Nothing about #include or the <...> is >>> specifically to do with headers (certainly not in my implementation). >> >> Ah, the old "it worked when I tried it on some compilers, therefore it >> must be correct" fallacy. The standard says that will work if you use >> the "..." form of #include, but does not require it for the <...> form. > > What's at issue is whether C's preprocessor's #include feature knows > about headers, or whether it's the other way around: C's way of > implementing headers is built on top of #include. Please explain what you mean by "knows about headers". The standard's definition of "header" (N1570 7.1.2p1) refers only to the standard library headers. `#include ` works *as if* a chunk of C code (the "entire contents of the header") were inserted at that point. The standard doesn't say how such a header is implemented or how its contents are represented. It's commonly a source file, but it may be something else. Of course the preprocessor know about headers -- *if* you accept the standard's definition of "headers". [...] > This suggests C could be defined without headers being a core part of > the language. And actually, it might work without #include (for new > programs), by synthesising the source file submitted to the compiler > from the text files that are to serve as headers. Sure, you could replace the preprocessor with some other tool that does the same thing. So what? > It would not be practical emulate modules in a language. Why not? Isn't "synthesising the source file submitted to the compiler from the text files that are to serve as headers" exactly what the preprocessor already does? > (This can be put to the test: take a source file s1.c, preprocess it to > s2.c so that #includes disappear, and then compile s2.c. It should still > work, but without #includes and without headers; magic! That's not magic, that's just how #include works. > Now try to do the same with a language with imports. I can't speak for > all such languages as they are all different, but with mine that would > definitely not be practical. (Partly because it needs the compiler to > generate the symbol information necessary to do the importing, even if > it's all done with text files.) So the issue isn't what #include or "header" means. Both of those concepts are well defined, in spite of your efforts to obfuscate them. The only open questions involve what you're calling "modules". That's a well defined term in some languages, but C itself has no such concept. Programmers commonly implement something that might reasonable be called "modules" using #include and libraries (and of course #include can be used for purposes other than implementing "modules"). Does the preprocessor "know" about "headers", as that term is defined in the standard? Of course it does. Does it know about "modules"? No, because there is no such concept defined in the language. C doesn't directly support modules, but programmers can implement them using the tools provided by the language. -- 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"