How best to provide a module

[James Harris]

If distributing a piece of code in C how is it best to provide it?
Options seem to be

1. Precompile the module.c file(s) to module.o and provide a header.
The using code then has

#include "module.h"

at the top and needs to be linked with the compiled module.

2. Include the source directly. The using code then has

#include "module.c"

at the lowest lexical level - i.e. not within a function. Are both of
these viable ways to include a separate piece of source code and and
are there any others?

--
TIA,
James

[Richard Heathfield]

James Harris said:

If distributing a piece of code in C how is it best to provide it?

It depends on your needs.

Options seem to be

1. Precompile the module.c file(s) to module.o and provide a header.
The using code then has

#include "module.h"

at the top and needs to be linked with the compiled module.

That's one way, and it's useful if you don't want to distribute the source.

2. Include the source directly. The using code then has

#include "module.c"

But that's *not* another way! :-) At least, it's a lousy, lousy idea. If
you're okay with the user having the source, just send them the source
(which you'd have to do anyway, for the above to "work"), and either rely
on them to, or tell them how to, compile it and link it into their
project. (You shouldn't need to tell them unless they're very new to C.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Harris]

On 21 Aug, 14:15, Richard Heathfield <[e-mail]:

James Harris said:

....

2. Include the source directly. The using code then has

#include "module.c"

But that's *not* another way! :-) At least, it's a lousy, lousy idea. If
you're okay with the user having the source, just send them the source
(which you'd have to do anyway, for the above to "work"), and either rely
on them to, or tell them how to, compile it and link it into their
project. (You shouldn't need to tell them unless they're very new to C.)

Haha! I've not seen anyone do this. But why is it always lousy? And
are there no circumstances where it would be good?

[Mike Wahler]

"James Harris" <ja************@googlemail.comwrote in message
news:cf**********************************@l42g2000 hsc.googlegroups.com...

On 21 Aug, 14:15, Richard Heathfield <[e-mail]:

>James Harris said:

...

2. Include the source directly. The using code then has

#include "module.c"

But that's *not* another way! :-) At least, it's a lousy, lousy idea. If
you're okay with the user having the source, just send them the source
(which you'd have to do anyway, for the above to "work"), and either rely
on them to, or tell them how to, compile it and link it into their
project. (You shouldn't need to tell them unless they're very new to C.)

Haha! I've not seen anyone do this.

I've seen it once or twice.

But why is it always lousy?

It can cause problems with duplicate definitions.

And
are there no circumstances where it would be good?

Never say never. :-)

But I recommend not to do it without some compelling
reason.

-Mike

[Wolfgang Draxinger]

James Harris wrote:

Haha! I've not seen anyone do this. But why is it always lousy?

Because it means, that you can include that module into only one
source file. If you include it multiple times, that you got a
bunch of object files all with the same identifiers clashing at
link time.

And are there no circumstances where it would be good?

No. Either provide a separate header, or just provide the source
file and let the other people extract a header with a bunch of
PERL code.

Wolfgang Draxinger
--
E-Mail address works, Jabber: he******@jabber.org, ICQ: 134682867

[Malcolm McLean]

"Wolfgang Draxinger" <wd********@darkstargames.dewrote in message

James Harris wrote:

>Haha! I've not seen anyone do this. But why is it always lousy?

Because it means, that you can include that module into only one
source file. If you include it multiple times, that you got a
bunch of object files all with the same identifiers clashing at
link time.

Simply make all the functions and globals static.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[James Harris]

On 21 Aug, 15:25, "Mike Wahler" <[e-mail]:
....

But why is it always lousy?

It can cause problems with duplicate definitions.

ok

And
are there no circumstances where it would be good?

Never say never. :-)

But I recommend not to do it without some compelling
reason.

Agreed.

[Eric Sosman]

Malcolm McLean wrote:

>
"Wolfgang Draxinger" <wd********@darkstargames.dewrote in message

>James Harris wrote:

>>Haha! I've not seen anyone do this. But why is it always lousy?

Because it means, that you can include that module into only one
source file. If you include it multiple times, that you got a
bunch of object files all with the same identifiers clashing at
link time.

Simply make all the functions and globals static.

Reduces the problem a bit, but does not solve it. To be sure,
it can't be solved completely: Name collisions are ultimately
unavoidable when integrating C code from multiple suppliers.
However, separate compilation has the virtue of limiting the
"exposed" identifiers to those with external linkage, the module's
public interface, more or less. Wholesale source inclusion, on the
other hand, brings *all* the module's identifiers out into the open
where they can collide with the user's names.

/* module.c */
void doThis(void) { ... }
void doThat(void) { ... }
static void helper(void) { ... }

The normal approach requires the rest of the program to avoid using
`doThis' and `doThat' as externally-linked identifiers. Wholesale
inclusion requires the including module to avoid `doThis' and
`doThat' *and* `helper' for *any* file-scope identifiers.

Also, the mention of "globals" suggests that the consequences
have not been thought through. If `static int global;' appears in
the #include'd module, then each translation unit that #includes it
gets its very own private version of `global'. If Module M1 sets
`global = 42;', Module M2 cannot detect it -- which sort of goes
against the purpose of having a "global" in the first place.

--
Er*********@sun.com

[Keith Thompson]

James Harris <ja************@googlemail.comwrites:

If distributing a piece of code in C how is it best to provide it?
Options seem to be

1. Precompile the module.c file(s) to module.o and provide a header.
The using code then has

#include "module.h"

at the top and needs to be linked with the compiled module.

That can work, but only if the module.o file is compatible with the
user's system. You could provide multiple versions of module.o for
different systems. It's a pain, but it's pretty much necessary if you
don't want to distribute your source code.

You might also consider distributing shrouded C source. There are
utilities that will automatically obfuscate C source code, so it will
still compile and have the same semantics but is practically very
difficult to read or modify.

But if you don't mind distributing your sources (and your second idea
suggests you don't), then you probably shouldn't bother.

2. Include the source directly. The using code then has

#include "module.c"

at the lowest lexical level - i.e. not within a function. Are both of
these viable ways to include a separate piece of source code and and
are there any others?

Bad idea. Just distribute two files, module.h and module.c.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bartc]

"James Harris" <ja************@googlemail.comwrote in message
news:95**********************************@2g2000hs n.googlegroups.com...

If distributing a piece of code in C how is it best to provide it?
Options seem to be

1. Precompile the module.c file(s) to module.o and provide a header.
The using code then has

#include "module.h"

at the top and needs to be linked with the compiled module.

2. Include the source directly. The using code then has

#include "module.c"

at the lowest lexical level - i.e. not within a function. Are both of
these viable ways to include a separate piece of source code and and
are there any others?

3. Precompile into a dynamic library. Distribute the library plus a .h file
or docs sufficient to make use of the library.

The format will vary between OSs, but is not so dependent on compiler (or,
to some extent, language).

--
Bartc

[Stephen Sprunk]

James Harris wrote:

On 21 Aug, 14:15, Richard Heathfield <[e-mail]:

>James Harris said:

...

>>2. Include the source directly. The using code then has
#include "module.c"

But that's *not* another way! :-) At least, it's a lousy, lousy idea. If
you're okay with the user having the source, just send them the source
(which you'd have to do anyway, for the above to "work"), and either rely
on them to, or tell them how to, compile it and link it into their
project. (You shouldn't need to tell them unless they're very new to C.)

Haha! I've not seen anyone do this. But why is it always lousy? And
are there no circumstances where it would be good?

It may allow some compilers to perform better optimization (such as
inlining) if the entire program is presented as a single translation unit.

S