I was wondering how people feel about including .c files in other .c files.
I saw a few occasions of this.
Triggered by that observation I decided to do a grep for this (on
2.6.25.7 as that was the one I had handy at that moment).
Some 268 .c files are included.
Seems an awful lot for me.
Do people feel this is good practice?
I understand that sometimes it is useful (and then you might need to
decide on whether to include a .c file or to have a .h file with
code), but in other places it is probably less relevant.
Generally I would expect that if the .c file contains some standalone
functionality then it should probably be a .c file on its own with a
well defined interface.
Curious what others think about this.
As attachement I've added the output of the grep (slightly edited to
remove some false positives, like those from the Documentation and
scripts directories and those who are obviously comments).
Frans.
"Frans Meulenbroeks" <[email protected]> writes:
> Generally I would expect that if the .c file contains some standalone
> functionality then it should probably be a .c file on its own with a
> well defined interface.
Doesn't work when you need conditional compilation.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> "Frans Meulenbroeks" <[email protected]> writes:
>
>
>>Generally I would expect that if the .c file contains some standalone
>>functionality then it should probably be a .c file on its own with a
>>well defined interface.
>
>
> Doesn't work when you need conditional compilation.
Sure it does...look at all the kernel Makefiles that compile code based
on whether a config option is set.
In the case of the scheduler I suspect it's done to break a single
logical file into several pieces for better readability.
Chris
On 08-08-08 13:25, Frans Meulenbroeks wrote:
> I was wondering how people feel about including .c files in other .c
> files.
>
> I saw a few occasions of this. Triggered by that observation I
> decided to do a grep for this (on 2.6.25.7 as that was the one I had
> handy at that moment). Some 268 .c files are included. Seems an awful
> lot for me.
>
> Do people feel this is good practice? I understand that sometimes it
> is useful (and then you might need to decide on whether to include a
> .c file or to have a .h file with code), but in other places it is
> probably less relevant.
>
> Generally I would expect that if the .c file contains some standalone
> functionality then it should probably be a .c file on its own with a
> well defined interface.
>
> Curious what others think about this. As attachement I've added the
> output of the grep (slightly edited to remove some false positives,
> like those from the Documentation and scripts directories and those
> who are obviously comments).
As you posted, many of these are in sound/ and many of those #define a
model and then including the "real source file". Can't say I've been
very keen on that either and in those cases using a -D commandline
#define might be better especially since I believe that's actually very
easy these days.
I also keep a local driver here though that #defines some 50 items and
then includes the source so that the driver for another version of the
card can just redefine those and keep the code itself the same (as a
coincidence, I was just porting that one forward in fact).
This general problem more or less is "library code". Say I have some
code that I want to use in two different drivers -- I can't just link it
into both due to symbol clashes if I'd try to then _load_ both drivers.
So I then have to structure the library code as a completely seperate
module that both drivers depend on and for small stuff that's sometimes
just really silly. You still definitely don't want two copies of the
code to avoid all the usual problems of stuff getting out of sync so a
solution is to just #include the library code in both after which its
identifiers can be static.
If you think about it -- in C, #include really at least conceptually
means "cut & paste this in here, please" meaning headers are not
anything special and .h and .c seperation is a mere convention.
As we all know, conventions exist _only_ to be violated...
Rene.
"Chris Friesen" <[email protected]> writes:
>> Doesn't work when you need conditional compilation.
>
> Sure it does...look at all the kernel Makefiles that compile code
> based on whether a config option is set.
Nope, I meant compilation depending on preprocessor variables defined
(or not) by the including file. CONFIG_* and things like make
variables are completely different things.
Imagine a chip driver (library) doing I/O using either MMIO or
inp/outp. The real card driver uses the library and provides
necessary glue code. You can either a) make I/O real function calls,
call using pointers etc. (slow, should be inline), or b) define the
I/O as inline functions or macros and then #include the library.
--
Krzysztof Halasa
Rene Herman wrote:
>
> If you think about it -- in C, #include really at least conceptually
> means "cut & paste this in here, please" meaning headers are not
> anything special and .h and .c seperation is a mere convention.
>
> As we all know, conventions exist _only_ to be violated...
>
The real issue is that the convention -- .c versus .h -- recognize *two*
kinds of files, but there really are *three* kinds of files:
- Files meant to be included that generate no code (.h)
- Files meant to be included that generate code (???)
- Files not meant to be included (.c)
Some projects -- including the Linux kernel -- have adopted the
convention that the middle type should be .c, others .h, others probably
other variants. You typically want them treated as .h files for
purposes of generating dependencies, but like .c files for purposes of,
say, header file include guard checking.
-hpa