C Programming Language :: Is it legal to include source file?


	Is it legal to include source file? Is it legal to do something like this: #include "x.c" in other source file? And is it good idea? Thank you in advance for your answers, Igor. mr.po@gmail.com said: > Is it legal to do something like this: > #include "x.c" in other source file? Yes. > And is it good idea? No. > Thank you in advance for your answers, > Igor. That'th all right, Igor. The uthual way to incorporate multiple thourtheth into one program ith to compile them theparately, and then link them together. For ecthample, if you are uthing the GNU compiler (which begth to be lithped, but I lack thuffithient thpittle), you might do thith: gcc -W -Wall -ansi -pedantic -c -o x.o x.c gcc -W -Wall -ansi -pedantic -c -o y.o y.c gcc -W -Wall -ansi -pedantic -c -o z.o z.c gcc -W -Wall -ansi -pedantic -o foo x.o y.o z.o Might I altho thuggetht that you invethtigate your implementathion'th third-party library fathilitieth? -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Richard Heathfield wrote: > mr.po@gmail.com said: >>Is it legal to do something like this: >>#include "x.c" in other source file? > Yes. >>And is it good idea? > No. > That'th all right, Igor. The uthual way to incorporate multiple > thourtheth into one program ith to compile them theparately, and then > link them together. Been to the dentist? ;-) There was a project several years ago in which I included a code file. I was writing serial I/O drivers for multiple ports, but using a single function and pointers/indexes to the data area associated with the port significantly increased the interrupt processing time. I wrote one procedure as a template, then had separate wrapper functions for each port which included the code file after setting a defined constant for the port value. For each driver the port was constant, so no run-time indexing or dereferencing was needed. The I/O ports were also directly addressed. Bottom line was that the code was defined in one place, and was instantiated in multiple places to optimize speed at the expense of code space. Come to think of it, that's similar to what happens with function-like macro usage, and inline functions, just a different way to invoke it. It's a technique, though, which I use only in special circumstances. -- Thad On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield - Hide quoted text - <r@see.sig.invalid> wrote: > mr.po@gmail.com said: >> Is it legal to do something like this: >> #include "x.c" in other source file? >Yes. >> And is it good idea? >No. >> Thank you in advance for your answers, >> Igor. >That'th all right, Igor. The uthual way to incorporate multiple What in the original post prompted you to be this snide? Any value in your response will be lost on all the participants who struggle through this group in a second language. Are you having a running battle with this poster in a different group? Remove del for email - Hide quoted text - Thad Smith wrote: > Richard Heathfield wrote: >> mr.po@gmail.com said: >>> Is it legal to do something like this: >>> #include "x.c" in other source file? >> Yes. >>> And is it good idea? >> No. > Bottom line was that the code was defined in one place, and was > instantiated in multiple places to optimize speed at the expense of code > space. Come to think of it, that's similar to what happens with > function-like macro usage, and inline functions, just a different way to > invoke it. > It's a technique, though, which I use only in special circumstances. I've seen it done where the same code is instantiated with multiple data types. As it was done that way by people more expert than the average of those whose code I inherit, I work with it, rather than pass judgment. Barry Schwarz said: > On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield > <r@see.sig.invalid> wrote: >> mr.po@gmail.com said: <snip> >>> Thank you in advance for your answers, >>> Igor. >>That'th all right, Igor. The uthual way to incorporate multiple > What in the original post prompted you to be this snide? What maketh you think I'm being thnide? Have you never read any Dithcworld bookth? -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. Thad Smith <ThadSm@acm.org> writes: > There was a project several years ago in which I included a code > file. I was writing serial I/O drivers for multiple ports, but using a > single function and pointers/indexes to the data area associated with > the port significantly increased the interrupt processing time. I > wrote one procedure as a template, then had separate wrapper functions > for each port which included the code file after setting a defined > constant for the port value. For each driver the port was constant, > so no run-time indexing or dereferencing was needed. The I/O ports > were also directly addressed. This technique sometimes makes sense, but I'd suggest that giving an included code file a .c extension is misleading. When I do something like this, I use a .inc or .def or other extension that is less likely to surprise programmers reading the code later. -- "Welcome to the wonderful world of undefined behavior, where the demons are nasal and the DeathStation users are nervous." --Daniel Fox On Sun, 03 Jun 2007 21:50:10 +0000, in comp.lang.c , Richard - Hide quoted text - Heathfield <r@see.sig.invalid> wrote: >Barry Schwarz said: >> On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield >> <r@see.sig.invalid> wrote: >>> mr.po@gmail.com said: ><snip> >>>> Thank you in advance for your answers, >>>> Igor. >>>That'th all right, Igor. The uthual way to incorporate multiple >> What in the original post prompted you to be this snide? >What maketh you think I'm being thnide? Have you never read any >Dithcworld bookth? I guess the problem is that your post could be construed as an insulting joke. Imagine if we insisted on comparing you to Richard the Third, hump and all, or invariably responded in Bronte-esque language and complained about how you'd treated Cathy? Igor is after all a real name as well as a running joke in Discworld. (and yes, I know you won't read this, you killfiled me because you thought I kept insulting you. Hmm, curiouser and curiouser..) -- Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan In article <a3c663tfkncqehikmudqfcdpt0ubek5@4ax.com>, Barry Schwarz <schwa@doezl.net> wrote: - Hide quoted text - > On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield > <r@see.sig.invalid> wrote: > > mr.po@gmail.com said: > >> Is it legal to do something like this: > >> #include "x.c" in other source file? > >Yes. > >> And is it good idea? > >No. > >> Thank you in advance for your answers, > >> Igor. > >That'th all right, Igor. The uthual way to incorporate multiple > What in the original post prompted you to be this snide? So I'm not alone? (I thought the same thing.) -- Don Bruder - dak@sonic.net - If your "From:" address isn't on my whitelist, or the subject of the message doesn't contain the exact text "PopperAndShadow" somewhere, any message sent to this address will go in the garbage without my ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info - Hide quoted text - Ben Pfaff wrote: > Thad Smith <ThadSm@acm.org> writes: >>There was a project several years ago in which I included a code >>file. I was writing serial I/O drivers for multiple ports, but using a >>single function and pointers/indexes to the data area associated with >>the port significantly increased the interrupt processing time. I >>wrote one procedure as a template, then had separate wrapper functions >>for each port which included the code file after setting a defined >>constant for the port value. For each driver the port was constant, >>so no run-time indexing or dereferencing was needed. The I/O ports >>were also directly addressed. > This technique sometimes makes sense, but I'd suggest that giving > an included code file a .c extension is misleading. When I do > something like this, I use a .inc or .def or other extension that > is less likely to surprise programmers reading the code later. God point, Ben. I think I used an extension of .ci. -- Thad Don Bruder said: - Hide quoted text - > In article <a3c663tfkncqehikmudqfcdpt0ubek5@4ax.com>, > Barry Schwarz <schwa@doezl.net> wrote: >> On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield >> <r@see.sig.invalid> wrote: >> > mr.po@gmail.com said: <snip> >> >> Thank you in advance for your answers, >> >> Igor. >> >That'th all right, Igor. The uthual way to incorporate multiple >> What in the original post prompted you to be this snide? > So I'm not alone? > (I thought the same thing.) Then I apologise unreservedly to the OP. Silly joke gone wrong. Sorry. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. In article <1180896625.488728.142@q75g2000hsh.googlegroups.com>, <mr.po@gmail.com> wrote: >Is it legal to do something like this: >#include "x.c" in other source file? Whether it will work or not is implementation defined. If my memory serves me correctly this evening, the preprocessor is only -required- to provide a token-to-filename mapping mechanism for the .h extension and for one directory. The C preprocessor is -allowed- to require the user to write the filename token in a manner quite different than the host operating system uses to name files. For example, there are operating systems that do not support lowercase letters, and do not support dots in filenames; the operating system might also happen to require a "drive letter" for each filename access (with no equivilent of a "current working directory".) The preprocessor could define (documenting it of course) that <foo.h> (for any foo) shall map to filename FOO (uppercaseing), file extension INC, drive Z, and could define that "foo.h" shall first try filename FOO file extension INC drive A, followed by FOO INC Z -- and the preprocessor could leave the transformation of all other filename forms undefined -- perhaps even looking in its public dataset catalog for a dataset named x.c rather than trying to find filename X file extension C drive A. -- Prototypes are supertypes of their clones. -- maplesoft In article <Bv2dncUtzLkukv7bnZ2dnUVZ8qrin@bt.com>, Richard Heathfield <r@see.sig.invalid> wrote: >> Is it legal to do something like this: >> #include "x.c" in other source file? >Yes. Agreed. >> And is it good idea? >No. But this depends entirely on what you're trying to achieve. I have a program that performs almost identical operations either on sequences of characters - represented as C strings - or on sequences of XML elements - represented as counted arrays of struct pointers. The low-level operations are different (for example, copying a sequence, determining when we have reached the end of a sequence), but the control structure is the same. I find it convenient to implement this by defining a few macros in two files and #including the main body of the code in each of them. This seems a completely reasonable technique to me. Of course there are other ways to do this. I could have abstracted the differences into structs containing functions pointers, at the expense of some overhead and the loss of a great deal of automatic type-checking. But I can see no reason to reject the use of #include to parametrise code at the lexical level. -- Richard -- "Consideration shall be given to the need for as many as 32 characters in some alphabets" - X3.4, 1963. Richard Tobin said: > In article <Bv2dncUtzLkukv7bnZ2dnUVZ8qrin@bt.com>, > Richard Heathfield <r@see.sig.invalid> wrote: >>> Is it legal to do something like this: >>> #include "x.c" in other source file? >>Yes. > Agreed. >>> And is it good idea? >>No. > But this depends entirely on what you're trying to achieve. Yes. Nevertheless, it remains the best answer to give a newbie. By the time it might be a good idea for him to do it, he'll know enough not to do it except when it's a good idea. <snip> -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. - Hide quoted text - Barry Schwarz <schwa@doezl.net> writes: > On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield > <r@see.sig.invalid> wrote: >> mr.po@gmail.com said: >>> Is it legal to do something like this: >>> #include "x.c" in other source file? >>Yes. >>> And is it good idea? >>No. >>> Thank you in advance for your answers, >>> Igor. >>That'th all right, Igor. The uthual way to incorporate multiple > What in the original post prompted you to be this snide? Any value in > your response will be lost on all the participants who struggle > through this group in a second language. Are you having a running > battle with this poster in a different group? It seems a common problem in this ng. - Hide quoted text - Mark McIntyre <markmcint@spamcop.net> writes: > On Sun, 03 Jun 2007 21:50:10 +0000, in comp.lang.c , Richard > Heathfield <r@see.sig.invalid> wrote: >>Barry Schwarz said: >>> On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield >>> <r@see.sig.invalid> wrote: >>>> mr.po@gmail.com said: >><snip> >>>>> Thank you in advance for your answers, >>>>> Igor. >>>>That'th all right, Igor. The uthual way to incorporate multiple >>> What in the original post prompted you to be this snide? >>What maketh you think I'm being thnide? Have you never read any >>Dithcworld bookth? > I guess the problem is that your post could be construed as an > insulting joke. > Imagine if we insisted on comparing you to Richard the Third, hump and > all, or invariably responded in Bronte-esque language and complained > about how you'd treated Cathy? or even Richard the Turd in the Irish vernacular. > Igor is after all a real name as well as a running joke in Discworld. > (and yes, I know you won't read this, you killfiled me because you > thought I kept insulting you. Hmm, curiouser and curiouser..) -- rober@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: > In article <1180896625.488728.142@q75g2000hsh.googlegroups.com>, > <mr.po@gmail.com> wrote: >>Is it legal to do something like this: >>#include "x.c" in other source file? > Whether it will work or not is implementation defined. If my memory > serves me correctly this evening, the preprocessor is only -required- > to provide a token-to-filename mapping mechanism for the .h extension > and for one directory. > The C preprocessor is -allowed- to require the user to write the > filename token in a manner quite different than the host operating system > uses to name files. [...] C99 6.10.2p4, p5: ... The method by which a sequence of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined into a single header name preprocessing token is implementation-defined. The implementation shall provide unique mappings for sequences consisting of one or more letters or digits (as defined in 5.2.1) followed by a period (.) and a single letter. The first character shall be a letter. The implementation may ignore the distinctions of alphabetical case and restrict the mapping to eight significant characters before the period. -- Keith Thompson (The_Other_Keith) k@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" On Sun, 03 Jun 2007 21:50:10 +0000, Richard Heathfield - Hide quoted text - <r@see.sig.invalid> wrote: >Barry Schwarz said: >> On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield >> <r@see.sig.invalid> wrote: >>> mr.po@gmail.com said: ><snip> >>>> Thank you in advance for your answers, >>>> Igor. >>>That'th all right, Igor. The uthual way to incorporate multiple >> What in the original post prompted you to be this snide? >What maketh you think I'm being thnide? Have you never read any >Dithcworld bookth? Nope, never heard of them. And based on your post, I can't tell if the title should be Discworld or Dizcworld. But then again, it doesn't really matter. Remove del for email Richard Heathfield wrote: > Barry Schwarz said: >> Richard Heathfield <r@see.sig.invalid> wrote: >>> mr.po@gmail.com said: > <snip> >>>> Thank you in advance for your answers, >>> That'th all right, Igor. The uthual way to incorporate multiple >> What in the original post prompted you to be this snide? > What maketh you think I'm being thnide? Have you never read any > Dithcworld bookth? Your answer. It may not appear so to you, but it does to the average reader. The fact that the enquiry was in good English does not overide the OPs name. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> <http://www.aaxnet.com/editor/edit043.html> <http://kadaitcha.cx/vista/dogsbreakfast/index.html> cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com Walter Roberson wrote: > <mr.po@gmail.com> wrote: >> Is it legal to do something like this: >> #include "x.c" in other source file? > Whether it will work or not is implementation defined. If my > memory serves me correctly this evening, the preprocessor is only > -required- to provide a token-to-filename mapping mechanism for > the .h extension and for one directory. Your memory is wrong. There is no reason to even assume the local file system has extensions. From N869: 4. Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed. If a character sequence that matches the syntax of a universal character name is produced by token concatenation (6.10.3.3), the behavior is undefined. A #include preprocessing directive causes the named header or source file to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> <http://www.aaxnet.com/editor/edit043.html> <http://kadaitcha.cx/vista/dogsbreakfast/index.html> cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com On Sun, 3 Jun 2007 22:27:54 +0000 (UTC), in comp.lang.c , rober@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote: >In article <1180896625.488728.142@q75g2000hsh.googlegroups.com>, > <mr.po@gmail.com> wrote: >>Is it legal to do something like this: >>#include "x.c" in other source file? >Whether it will work or not is implementation defined. If my memory >serves me correctly this evening, the preprocessor is only -required- >to provide a token-to-filename mapping mechanism for the .h extension >and for one directory. AFAIR the interpretation of the token between the "" or <> is left to the implementation. -- Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan Richard Heathfield wrote: > mr.po@gmail.com said: > > Is it legal to do something like this: > > #include "x.c" in other source file? > Yes. > > And is it good idea? > No. [...] It has its uses. Consider a file which is included in a "project" (quotes used because C doesn't define the word, but most people can infer its meaning from context), which is also included, in a slightly different customized version, in another "project". The customized version uses a file that consists solely of: #define USE_CUSTOM_VERSION #include "generic_version.c" The "generic_version.c" source file then has some #ifdef's on the USE_CUSTOM_VERSION name to make different versions. Yes, this could be done by using command-line flags to #define the symbol for you, but this is compiler-specific, especially when you consider that you might want both "object files" to be available without recompiling, whereas the two-file method is portable. -- +-------------------------+--------------------+-----------------------+ \| Kenneth J. Brody \| www.hvcomputer.com \| #include \| \| kenbrody/at\spamcop.net \| www.fptech.com \| <std_disclaimer.h> \| +-------------------------+--------------------+-----------------------+ Don't e-mail me at: <mailto:ThisIsASpamT@gmail.com> On Sun, 03 Jun 2007 19:02:18 +0000, Richard Heathfield - Hide quoted text - <r@see.sig.invalid> wrote: > mr.po@gmail.com said: >> Is it legal to do something like this: >> #include "x.c" in other source file? >Yes. >> And is it good idea? >No. >> Thank you in advance for your answers, >> Igor. >That'th all right, Igor. The uthual way to incorporate multiple >thourtheth into one program ith to compile them theparately, and then >link them together. For ecthample, if you are uthing the GNU compiler >(which begth to be lithped, but I lack thuffithient thpittle), you >might do thith: >gcc -W -Wall -ansi -pedantic -c -o x.o x.c >gcc -W -Wall -ansi -pedantic -c -o y.o y.c >gcc -W -Wall -ansi -pedantic -c -o z.o z.c >gcc -W -Wall -ansi -pedantic -o foo x.o y.o z.o >Might I altho thuggetht that you invethtigate your implementathion'th >third-party library fathilitieth? What brought that on? -- Al Balmer Sun City, AZ Believe it or not, I wrote: >>Might I altho thuggetht that you invethtigate your implementathion'th >>third-party library fathilitieth? Al Balmer said: > What brought that on? You have to be a Discworld aficionado to understand. My apologies again to the OP. -- Richard Heathfield "Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk email: rjh at the above domain, - www. In article <lnodjwvbe1.@nuthaus.mib.org>, Keith Thompson <k@mib.org> wrote: - Hide quoted text - >rober@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: >> In article <1180896625.488728.142@q75g2000hsh.googlegroups.com>, >> <mr.po@gmail.com> wrote: >>>Is it legal to do something like this: >>>#include "x.c" in other source file? >> Whether it will work or not is implementation defined. If my memory >> serves me correctly this evening, the preprocessor is only -required- >> to provide a token-to-filename mapping mechanism for the .h extension >> and for one directory. >C99 6.10.2p4, p5: > ... The method by which a sequence of preprocessing tokens between > a < and a > preprocessing token pair or a pair of " characters is > combined into a single header name preprocessing token is > implementation-defined. > The implementation shall provide unique mappings for sequences > consisting of one or more letters or digits (as defined in 5.2.1) > followed by a period (.) and a single letter. The first character > shall be a letter. The implementation may ignore the distinctions > of alphabetical case and restrict the mapping to eight significant > characters before the period. Thanks for the clarification, Keith. Checking, I see that C89 only required support for six significant characters, and I also see that in C89 there was no mandatory support for digits in the sequence. I was definitely wrong about 'h' being the only extension that needs to be supported, and since the OP did live within the single-letter extension limit, that makes my caveat to the OP overall incorrect. -- "law -- it's a commodity" -- Andrew Ryan (The Globe and Mail, 2005/11/26)