Shared header-file?

[Han from Lule]

Hi,

I am currently working on a project where I having one serial version
and one parallel version of the code.
The layout is as follows:

Caller.h and .c: Always serial
calls
Worker.h, which has to versions
Serial_Worker.c and Parallel_Worker.c.
Both Serial_Worker and Parallel_Worker has only Worker.h as include.

My question is: Is it good practice to do it this way, or should I let
Serial_Worker and Parallel_Worker one header file each, who in turn
only include Worker.h? What are the pros and cons with respctive
method?

It is not important to choose in runtime which verison to use, it is
done in linking.

Thanks,
Krikko

 

[Keith Thompson]

That doesn't seem right.
That suggests that Worker.h
has delclarations for functions in both c files.
It seems strange for a preprocessing translation unit
to declare functions which aren't defined in it.

Really? If I have a #include <stdio.h>, my preprocessing translation
unit declared printf but doesn't define it. That's largely what
header files are for. Or did I misunderstand your point?

I'd say yes. If I understand correctly:

Worker.h declares:
void foo(void);
void bar(void);

Serial_Worker.c defines:
void foo(void) { /* serial implementation */ }
void bar(void) { /* serial implementation */ }

Parallel_Worker.c defines:
void foo(void) { /* parallel implementation */ }
void bar(void) { /* parallel implementation */ }

In other words, you have two different implementations of exactly the
same interface. Declaring that interface in a single header file
seems perfectly reasonable.

I have two list library files:
One is list_lib.c and the other is list_io.c

list_io.c is for a function which has a FILE type parameter
and stdio.h is #included in list_io.h.

Both of list_io.h and list_lib.h
#include a third header file: list_type.h

http://www.mindspring.com/~pfilandr/C/lists_and_files/

It sounds like that's a different situation. You have two different
interfaces, one using FILE and not, so of course you have two
different headers, list_io.h and list_lib.h (with shared declarations
in list_type.h).

[...]

A note to the original poster: "Han from China" is the pseudonym of a
rather nasty troll who has taken up residence in this group. You
might want to consider whether you want to identify yourself by a
name, "Han from Lule", that seems to be a reference to HfC. Just a
piece of friendly advice.

 

[Stephen Sprunk]

I am currently working on a project where I having one serial version
and one parallel version of the code.
The layout is as follows:

Caller.h and .c: Always serial
calls
Worker.h, which has to versions
Serial_Worker.c and Parallel_Worker.c.
Both Serial_Worker and Parallel_Worker has only Worker.h as include.

My question is: Is it good practice to do it this way, or should I let
Serial_Worker and Parallel_Worker one header file each, who in turn
only include Worker.h? What are the pros and cons with respctive
method?

It is not important to choose in runtime which verison to use, it is
done in linking.

This is a fairly common tactic: the single common header declares an
interface that the two source files implement (i.e. define) in different
ways, and only one of them is linked in.

I've found this particularly useful when presenting a "portable"
interface (e.g. for sockets or threads) to the rest of your program when
you have multiple system-specific implementations (e.g. POSIX, Win32)
from which you can select at compile/link time.

S

 

[Richard Bos]

According to the Jargon File definition of a troll, Keith is
trolling when he writes the above inflammatory comment. Surely he
expected the predictable reaction.

That's a pretty pathetic lie; you know perfectly well that a troll posts
_because of_ the predictable reactions, and not, as we both know Keith
does, _despite_ them.

* See thread titled:
More proof of errors going uncorrected among the "regs"

What a sorry old man.

Yes, you are. Even more pathetic than your lie above is the tendency,
not _just_ yours but particularly yours, to start new threads on old
subjects just to shout down your own sense of inferiority. If the
"regs", whoever they are, make an error, correct them _there and then_.
Pretending to do so at a later time, in a different thread, merely
showcases your own pitiable desire for attention.

Richard

 

[Richard Bos]

The first sentence or just the second? If you think the first sentence
is a lie, put up or shut up: Show how Keith escapes the Jargon File
definition of a troll when he makes such comments. In particular,
use the Jargon File definition of a troll to differentiate Keith
from me. If you mean only the second sentence, then see below.

The second derives from the first; and _do_ see below.

That's an absurd distinction. You can't read Keith's mind any more
than I can. Whether he's posting _because_ of the predictable
reactions or _despite_ them, which neither one of us can tell
for sure, he's still _expecting_ them

That is not the point. The point is that the Jargon File definition of a
troll is a post (and I quote) "designed to attract predictable responses
or flames", or someone who makes such posts. Note: _designed to_.
Now, as you very perspicaciously note, I cannot read either Keith's mind
nor, mercifully, yours. However, I think the balance of likelihood is
overwhelming that Keith's posts are not _designed to_ attract
predictable responses.

And I will keep providing threads as evidence of my assertions,
instead of just making assertions without evidence as some people do.

I do not say that you should not provide evidence, I say that _starting
a new thread_ just to do so smacks of narcissism coupled with low
self-esteem.

Richard

 

[Phil Carmody]

The second derives from the first; and _do_ see below.


That is not the point. The point is that the Jargon File definition of a
troll is a post (and I quote) "designed to attract predictable responses
or flames", or someone who makes such posts. Note: _designed to_.
Now, as you very perspicaciously note, I cannot read either Keith's mind
nor, mercifully, yours. However, I think the balance of likelihood is
overwhelming that Keith's posts are not _designed to_ attract
predictable responses.

Au contraire! I think Keith's posts are designed to attract
responses as predictable as "aha!" and "thank you".

Phil

 

[jameskuyper]

(e-mail address removed) (Richard Bos) writes: ....

Au contraire! I think Keith's posts are designed to attract
responses as predictable as "aha!" and "thank you".

Anyone who makes that prediction hasn't been paying attention to this
newsgroup.