Is it legal to include source file?

[mr.polik]

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.

 

[Richard Heathfield]

(e-mail address removed) 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?

 

[Barry Schwarz]

(e-mail address removed) said:


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

 

[Thad Smith]

(e-mail address removed) said:


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.

 

[Tim Prince]

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.

 

[Ben Pfaff]

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.

 

[Richard Heathfield]

Barry Schwarz said:

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?

 

[Mark McIntyre]

Barry Schwarz said:


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

 

[Don Bruder]

What in the original post prompted you to be this snide?

So I'm not alone?

(I thought the same thing.)

 

[Richard Heathfield]

Don Bruder said:

So I'm not alone?

(I thought the same thing.)

Then I apologise unreservedly to the OP. Silly joke gone wrong. Sorry.

 

[Walter Roberson]

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.

 

[Thad Smith]

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.

 

[Richard Tobin]

Is it legal to do something like this:
#include "x.c" in other source file?

Yes.

Agreed.

And is it good idea?

[/QUOTE]

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

 

[Richard Heathfield]

Richard Tobin said:

Agreed.

No.

But this depends entirely on what you're trying to achieve.[/QUOTE]

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]

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.

 

[Richard]

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..)

--

 

[Keith Thompson]

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.

 

[Barry Schwarz]

Barry Schwarz said:


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

 

[Mark McIntyre]

On Sun, 3 Jun 2007 22:27:54 +0000 (UTC), in comp.lang.c ,

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

 

[Kenneth Brody]

(e-mail address removed) said:


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:[email protected]>