lkml.org 
[lkml]   [2008]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: including .c files ?
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.


\
 
 \ /
  Last update: 2008-08-08 17:39    [W:0.189 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site