Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: To include or not to include Date: Tue, 27 Sep 2016 12:38:30 -0700 Organization: None to speak of Lines: 71 Message-ID: References: <87zimyhk54.fsf@bsb.me.uk> <87a8ewgb5y.fsf@bsb.me.uk> <87r388dzw9.fsf@bsb.me.uk> <87vaxhbhhi.fsf@bsb.me.uk> <87inthbf8o.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="32071"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18aCyirae6qkoexvI0tu8Uu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:R+P0Ctx3biOjpvnO2oJ5/YIqsPk= sha1:++k3CLxmsf5+ruuWKHpYMFP4OrU= Xref: csiph.com comp.lang.c:94160 BartC writes: > On 27/09/2016 19:42, Keith Thompson wrote: >> BartC writes: > >>> gcc A.c X.c Y.c >> >> Was that intended to explain what you mean by the word "module"? > > >> Let me ask directly: What exactly do you mean by the word "module"? > > The same as as 'module' means in any of dozens of languages. What it means in some other languages is a language-level construct called a "module" (or a "package"), and the details can vary from one language to another. C has no such language-level construct. >> If >> it's a synonym for "translation unit" or "source file", can you just use >> that term instead? > > 'module' isn't exactly the same as those. A source file can comprise > other source files via include; or it can itself be part of another. A source file is just a file. It can contain #include directives that tell the preprocessor to open other files when processing it, but those other files are not part of the source file. > While a 'translation unit' I guess is what you get after you submit a > top-level source file to a compiler and it does a preprocessor pass. Syntactically, a translation-unit is defined as a sequence of zero or more external-declarations (function-definitions or declarations). N1570 5.1.1.1 defines the various terms (using * to denote italics, i.e., definitions): A C program need not all be translated at the same time. The text of the program is kept in units called *source files*, (or *preprocessing files*) in this International Standard. A source file together with all the headers and source files included via the preprocessing directive #include is known as a *preprocessing translation unit*. After preprocessing, a preprocessing translation unit is called a *translation unit*. > A 'module' corresponds more to an individual file as given to a > compiler, but also encompassing everything needed to define the module, > and without needing to half-compile it first. > > C being C, it naturally makes it hard to be more precise: three > source-files A, B and C, of 500 lines each, each include the same header > file H of 10000 lines. So most of the 'translation unit' is actually > common between the three. Yes, most of the translation units derived from the source files A, B, and C is derived from H. (The version of H that's included might not be the same if it depends on macros defined in A, B, and/or C.) I'm still not at all clear what you mean by "module", or how it differs from a translation unit. The phrase "everything needed to define the module" seems a bit circular. Can you give an example of something that's a translation unit but not a "module", or vice versa? And if so, how is the concept of a "module" useful? -- 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"