what is the best way

[Malcolm McLean]

I've never found this to be a significant burden, but I do spend
some time in trying to make interfaces as clean as possible.

The problem is that whizzbanggui.c contains the typedef of a struct point.
You're implementing pythagoras, which takes two points. So naturally they
get passed as struct points. But now everyone has to pull in the whole of
whizzbanggui, just to use that trivial definition.
If you define your own struct Point / struct myPoint, then you need adapter
code to convert between two identical structures when calling pythagoras
and whizzbanggui from the same program. So that's not a good solution either.

 

[Malcolm McLean]

Ah, I see a different in metaphor here.

I would describe the collection of source files (typically in their own
directory with a makefile) used to implement the interface declared in a
header as a module. You appear to be describing an individual source
file as a module.

I try to keep one module per file.

So, for example, lets say I'm writing a string-intensive program that does a
lot of counting of characters. I might have one module that does DNA
sequences, and another that does protein sequences.
So they'll both have

/* count the number of times ch appears in str */
static int countchars(char *str, int ch)

defined in the source file, purely to keep modules as one file, depending
on nothing else.

But if a file becomes too complex, I will reluctantly split it.

 

[Les Cargill]

The problem is that whizzbanggui.c contains the typedef of a struct point.

Uh oh.

You're implementing pythagoras, which takes two points. So naturally they
get passed as struct points. But now everyone has to pull in the whole of
whizzbanggui, just to use that trivial definition.

There's an entire ... discipline? in the art of stacking boxes
on top of other boxes so that everything is covered. Bad as I hate to
admit it, to my ear, a "point" is an object and unless it has
exactly one client/user, it has to be published in a reasonable manner.

Maybe you have a "primiTypes.h". Maybe you have "point.h".

If you define your own struct Point / struct myPoint, then you need adapter
code to convert between two identical structures when calling pythagoras
and whizzbanggui from the same program. So that's not a good solution either.

Or you could make "point" either completely independent in the two, or
make "point" a standalone object, or....

 

[Ian Collins]

I try to keep one module per file.

So, for example, lets say I'm writing a string-intensive program that does a
lot of counting of characters. I might have one module that does DNA
sequences, and another that does protein sequences.
So they'll both have

/* count the number of times ch appears in str */
static int countchars(char *str, int ch)

You forgot the const

defined in the source file, purely to keep modules as one file, depending
on nothing else.

That looks like code duplication for the sake of a doctrine. This
sounds like a text book example of when to use a shared library.

But if a file becomes too complex, I will reluctantly split it.

That depends on your definition of "too complex". Another good reason
for splitting is "too slow": when a monolithic file takes longer to
compile than the equivalent set of smaller files.

 

[Malcolm McLean]

Malcolm McLean wrote:

That looks like code duplication for the sake of a doctrine. This
sounds like a text book example of when to use a shared library.

It's not doctrine for the sake of doctrine. It's so I can take the file
dna.c, and have a list of functions that operate on dna sequences, which I
can use for another program. I can do the same with proteins.c. I can
take both files or one file, and they won't interact with each other.

 

[Ian Collins]

It's not doctrine for the sake of doctrine. It's so I can take the file
dna.c, and have a list of functions that operate on dna sequences, which I
can use for another program. I can do the same with proteins.c. I can
take both files or one file, and they won't interact with each other.

Or you could simply build a (shared) library.

 

[Malcolm McLean]

Or you could simply build a (shared) library.

More trouble than it's worth.
You want to be able to distribute the source. The receiver can then compile
it on his own system, hopefully just by typing cc *.c or an equivalent. He
doesn't want to have to mess about with libraries.