Including source

[squaretriangle]

Regarding either of the following:

1. Including a .c file with #include,
2. Including source code contained in a .h header file with #include

I have 2 questions.

1. Is the reality of most programmers not doing this because of
popular habit, or is it officially deprecated in one of the C
standard(s)?
2. What are the practical virtues of not doing it? I can think of
reasons *to* do it.

[santosh]

sq************@hotmail.co.uk wrote:

Regarding either of the following:

1. Including a .c file with #include,
2. Including source code contained in a .h header file with #include

I have 2 questions.

1. Is the reality of most programmers not doing this because of
popular habit, or is it officially deprecated in one of the C
standard(s)?

Headers usually get included into multiple translation units. Such
multiple inclusion of a .c file is likely to be an error.

2. What are the practical virtues of not doing it?

If you find yourself needing to include code sequences into multiple
files, you might consider multiple modules and linking. It greatly
reduces chances for conflict and code size. Any errors can be corrected
in one place instead of in umpteen files.

I can think of reasons *to* do it.

Okay, what are they?

[squaretriangle]

On 21 Oct, 19:54, santosh <[e-mail]:

I can think of reasons *to* do it.

Okay, what are they?

I was speaking from presumption; I'd never actually gone and tried
it. I was thinking that including a conditional to check if the file
had already been included would work, but on reflection it obviously
wouldn't. I was thinking that it would be more modular and easy to
deal with if a "library" could be included as one file, without having
to also think about linking to anything.

[santosh]

sq************@hotmail.co.uk wrote:

On 21 Oct, 19:54, santosh <[e-mail]:

I can think of reasons *to* do it.

Okay, what are they?

I was speaking from presumption; I'd never actually gone and tried
it. I was thinking that including a conditional to check if the file
had already been included would work, but on reflection it obviously
wouldn't.

It would work. That's exactly the mechanism that headers use. However
then you've defeated your own purpose.

I was thinking that it would be more modular and easy to
deal with if a "library" could be included as one file, without having
to also think about linking to anything.

A library by definition is called from several files and several
programs. You usually _don't_ want to include a fresh copy of a
function in each module that uses it. That's why multiple modules and
linking were developed.

The whole issue proceeds from the observation that, in C at least, you
generally need a separate declaration in each place it's needed, but
usually one definition of an object or function suffices. In fact for
external objects or functions, you cant have more than one active
definition.

A prominent exception to this observation are macros.

[Tor Rustad]

sq************@hotmail.co.uk wrote:

Regarding either of the following:

1. Including a .c file with #include,
2. Including source code contained in a .h header file with #include

I have 2 questions.

1. Is the reality of most programmers not doing this because of
popular habit, or is it officially deprecated in one of the C
standard(s)?

The way we use a function multiple places, is by placing the prototype
of the function in a header file, e.g. like this:

extern void function(void);

If you rather include the source of the function multiple places, this
leads to bloat, slower compile and possibly hard to maintain code.

2. What are the practical virtues of not doing it? I can think of
reasons *to* do it.

In 20 years of C programming, I have never needed or wanted to do it. :)

The only reason I can think of right now, is if I somehow wanted to
avoid using a function pointer as a parameter to an interface, for
tuning purposes. It sound like a bad idea...

--
Tor <torust [at] online [dot] no>

"Technical skill is mastery of complexity, while creativity is mastery
of simplicity"

[Pierre Asselin]

santosh <sa*********@gmail.comwrote:

sq************@hotmail.co.uk wrote:

1. Including a .c file with #include,
[ ... ]
I can think of reasons *to* do it.

Okay, what are they?

I'm not the OP but I found it useful to #include source files when
compiling unit tests. It's a bit idiosyncratic and is not done
when compiling the production code.

So it works, there is no prohibition against it, but it's not
normal.
--
pa at panix dot com

[Ben Pfaff]

sq************@hotmail.co.uk writes:

1. Including a .c file with #include,

[...]

2. What are the practical virtues of not doing it? I can think of
reasons *to* do it.

One good reason is a social one: programmers do not expect .c
files to be #included, so if you #include .c files, you will
surprise other programmers reading your code, making it more
difficult for them to maintain and enhance it.
--
Ben Pfaff
http://benpfaff.org

[James Kuyper Jr.]

sq************@hotmail.co.uk wrote:

Regarding either of the following:

1. Including a .c file with #include,
2. Including source code contained in a .h header file with #include

I have 2 questions.

1. Is the reality of most programmers not doing this because of
popular habit, or is it officially deprecated in one of the C
standard(s)?
2. What are the practical virtues of not doing it? I can think of
reasons *to* do it.

I've #included *.c files, but only for one specialized use: creating
wrappers for existing functions that modify the normal behavior of those
functions, and need to be link compatible with code that calls those
functions by name. I usually use this when creating unit test drivers.

wrapper.c:

#define origfunction myfunction
// file.c defines origfunction(). With the above #define, it actually
// ends up defining myfunction()
#include "file.c"
#unddef origfunction

long origfunction(int a, double b, char *c)
{
if(special_handling)
{
// implement special handling
}
else
{
return myfunction(a, b, c);
}
}
I prefer this over creating a modified copy of file.c, because I don't
need to make changes to wrapper.c, just because file.c changes, unless
the interface to origfunction() changes. This is particularly helpful
when origfunction() is part of a 3rd party library delivered as source
code, which describes all of the 3rd party libraries we link to in my group.

[borkhuis]

On Oct 21, 9:36 pm, santosh <[e-mail]:

[e-mail] wrote:

I was thinking that it would be more modular and easy to
deal with if a "library" could be included as one file, without having
to also think about linking to anything.

A library by definition is called from several files and several
programs. You usually _don't_ want to include a fresh copy of a
function in each module that uses it. That's why multiple modules and
linking were developed.

I do use it (but very rarely) for libraries. I have a library that
interfaces to a device driver, and can be used on several platforms
with different drivers for the same device. Most of the code is
generic, but part of it is platform dependent. I only want the defined
interface to be visible outside of the library, and not my internal
functions, so I want to define these functions as static.
I have four options to do this AFAIK:
I can create a number of copies of the generic code for each of the
platforms, which adds to the maintenance.
Or I can add the code for all the platform to the original file, and
use #ifdef to select the code I need for a platform.
Or I can create a source-file per platform that is included for a
specific platform only, also using #ifdef
Or do not define the functions as static.

We are using the third option, as this option is easier to maintain
than the first 2. The last one contradicts the "for internal use only"
rule for these functions, so this is a no-op.

Kind regards,
Johan Borkhuis