Callling a function from another file...

[sagar]

Hi,
I have a C file(add.c) in which i have a function called add.now
i want to call the same add function from another file sub.c .Can any1
tell how to do that...

Thanks in advance
Mark

 

[Francine.Neary]

Hi,
I have a C file(add.c) in which i have a function called add.now
i want to call the same add function from another file sub.c .Can any1
tell how to do that...

Please don't use silly txt-speak here.

Make sure add has external linkage, put a prototype for it at the
start of sub.c and away to go.

 

[Platonic Solid]

Hi,
I have a C file(add.c) in which i have a function called add.now
i want to call the same add function from another file sub.c .Can any1
tell how to do that...

I would do this:

/* add.c */

add(a, b)
int a; int b;
{
return (a+b);
}


/* sub.c */

sub(a, b)
int a; int b;
{
int add();
b=~b;
return ( add(a, ++b) );
}

 

[John Bode]

Hi,
I have a C file(add.c) in which i have a function called add.now
i want to call the same add function from another file sub.c .Can any1
tell how to do that...

Thanks in advance
Mark

The canonical way to do this is to create a header file that contains
a declaration for the function in prototype syntax, and #include it in
both the file that defines the function (add.c) and the file that
calls it (sub.c).

/*
* add.h
*/
#ifndef ADD_H
#define ADD_H

extern int add(int a, int b); /* I'm assuming that add takes ints */
/* and returns an int */

#endif

/*
* add.c
*/
#include "add.h"

int add(int a, int b)
{
/* do something interesting and return a value */
}

/*
* sub.c
*/
#include "add.h"

int sub(int a, int b)
{
int x;
...
x = add(a,b);
...
return x;
}

Now, you need to compile and link in such a way that both files are
built into the same executable. I don't know what environment you are
using, but here's a quick example using gcc:

gcc -o test sub.c add.c

 

[Keith Thompson]

Please don't use silly txt-speak here.

Make sure add has external linkage, put a prototype for it at the
start of sub.c and away to go.

Better: put the prototype in add.h, and add '#include "add.h"' to both
add.c and sub.c.

 

[CBFalconer]

Please don't use silly txt-speak here.

Make sure add has external linkage, put a prototype for it at the
start of sub.c and away to go.

Surely the OP meant to call "add", not "add.now". The way to
handle this is to remove any static in add.c describing the
function add, make a header file add.h which has the prototype for
add (and include it in add.c). Also include it in sub.c. All
done.

But don't start generating loose prototypes with no connection to
anything.

 

[Jack Klein]

I would do this:

/* add.c */

add(a, b)
int a; int b;

If you would do this, you would never get a job as a C programmer in a
legitimate shop.

[snip]

I don't think anybody in this group will take someone seriously who
hasn't noticed that this style of function definition became obsolete
in C. EIGHTEEN YEARS AGO.

If you know better and you are trolling, just say so and I will plonk
you.

If you don't know better, buy a modern book on C, such as K&R 2 from
1989. Read and understand it before you post here again.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

Surely the OP meant to call "add", not "add.now".

[...]

The OP simply neglected to add a space or two after the period, and to
capitalize the first word of the next sentence.

Translated to standard English:

I have a C file, add.c, in which I have a function called add.
Now I want to call the same add function from another file, sub.c.
Can anyone tell how to do that?

 

[Platonic Solid]

I would do this:

/* add.c */

add(a, b)
int a; int b;

If you would do this, you would never get a job as a C programmer in a
legitimate shop.

[snip]

I don't think anybody in this group will take someone seriously who
hasn't noticed that this style of function definition became obsolete
in C. EIGHTEEN YEARS AGO.

If you know better and you are trolling, just say so and I will plonk
you.

If you don't know better, buy a modern book on C, such as K&R 2 from
1989. Read and understand it before you post here again.

The situation is this: I am a hobbyist programmer and I've recently been
learning C from some old lecture notes. I've been told that some of the
syntax they use is now deprecated, but since all compilers will happily
compile the syntax I know, I don't really think there's any need to
start all over from the beginning. Especially as you can mix and match
old-style and new-style in the same program without any difficulty.

I also remember reading that this group caters for C according to any
standard version, including the "standard before the standard".

 

[Richard Heathfield]

Platonic Solid said:

<snip>

[K&R-style function declarators]

The situation is this: I am a hobbyist programmer and I've recently been
learning C from some old lecture notes. I've been told that some of the
syntax they use is now deprecated, but since all compilers will happily
compile the syntax I know, I don't really think there's any need to
start all over from the beginning. Especially as you can mix and match
old-style and new-style in the same program without any difficulty.

I also remember reading that this group caters for C according to any
standard version, including the "standard before the standard".

In a way, you are correct. K&R-style function declarators are certainly
topical, and in fact they remain legal C even in C99 (except for the
implicit int part, but even that is legal C90).

It is certainly a good idea to be aware of K&R-style declarators. Using
them in new code, however, is a less good idea. Just because a construct
is legal C (or even legal legacy C) and therefore topical in clc, that
doesn't automatically make it a bright thing to do!

Whilst I sympathise with your reluctance to obsolesce a construct in which
you have invested learning time, there are occasions where it's best to
bite the bullet and learn the "new"[1] way of doing things, and this is
certainly one of those occasions. Fortunately, prototype-style function
declarations are *easier* to learn than K&R style, they are quicker to
type, they are easier to maintain, and they have the added advantage of
giving the compiler more scope for type-checking. It's a win-win-win-win
situation.

[1] After 18 years, I think the irony quotes are justified.

 

[Jack Klein]

On 24 Sep 2007 at 22:01, sagar wrote:
Hi,
I have a C file(add.c) in which i have a function called add.now
i want to call the same add function from another file sub.c .Can any1
tell how to do that...

I would do this:

/* add.c */

add(a, b)
int a; int b;

If you would do this, you would never get a job as a C programmer in a
legitimate shop.

[snip]

I don't think anybody in this group will take someone seriously who
hasn't noticed that this style of function definition became obsolete
in C. EIGHTEEN YEARS AGO.

If you know better and you are trolling, just say so and I will plonk
you.

If you don't know better, buy a modern book on C, such as K&R 2 from
1989. Read and understand it before you post here again.

The situation is this: I am a hobbyist programmer and I've recently been
learning C from some old lecture notes. I've been told that some of the
syntax they use is now deprecated, but since all compilers will happily
compile the syntax I know, I don't really think there's any need to
start all over from the beginning. Especially as you can mix and match
old-style and new-style in the same program without any difficulty.

That is possible, but a very bad idea.

There is absolutely no question that adding prototypes to the language
is the single most significant improvement in the history of the C
language.

While there are still, perhaps, a few old UNIX kernels that can only
be compiled with antique, pre-ANSI compilers, it would be almost
impossible today to find a current compiler that could not accept at
least ANSI 1989/ISO 1990 C.

Writing new code using non-prototype function definitions is at best
foolish, at worst malicious. But submitting code samples to newbies
in this group using non-prototype function definitions, or
recommending that as a coding practice to newbies, is intolerable and
will only serve to get you pummeled repeatedly.

I also remember reading that this group caters for C according to any
standard version, including the "standard before the standard".

Yes, indeed, if someone has to deal with such code, for example to
update an ancient legacy application or deal with a very old third
party library. But I wouldn't say that this group supports anyone
writing per-standard C.

There are a number of more modern tutorials available online, some are
listed in the answer to question 18.9 of this newsgroup's FAQ (link in
my signature). Of these, Tom Torf's tutorial and Steve Summit's class
notes at eskimo.com are well regarded.

Come join us in the 21st century.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

There is absolutely no question that adding prototypes to the language
is the single most significant improvement in the history of the C
language.

[...]

Even more significant than allowing trailing commas in enumeration
type declarations?

 

[Old Wolf]

Platonic Solid said:

You have to define the function the same way you declared it
though; e.g. you can't have a prototype declaration and a
K&R style definition. (The compiler is not required to
diagnose this either, you just get weird runtime behaviour).

Fortunately, prototype-style function
declarations are [...] quicker to type,

Not if the K&R style was:
int func( a, b, c, d )
volatile unsigned char *a, *b, *c, *d;
{ .... }

(In fact, this argument was used by my C tutor at polytech
way back when, as to why he preferred K&R style).

 

[Old Wolf]

There is absolutely no question that adding prototypes to the language
is the single most significant improvement in the history of the C
language.

Every time my compiler catches an error due to the
function call not matching the prototype, I reflect
for a moment on how much time I would have wasted
debugging if that error had not been reported.

 

[Keith Thompson]

Every time my compiler catches an error due to the
function call not matching the prototype, I reflect
for a moment on how much time I would have wasted
debugging if that error had not been reported.

Indeed. One of the very first C programs I wrote had an error in it:
the number of arguments in a call didn't match the number of
parameters in the declaration. The compiler didn't make a peep; it
just compiled it and generated bad code. I was *horrified*.

Prototypes are good.

 

[Richard Heathfield]

Old Wolf said:

Fortunately, prototype-style function
declarations are [...] quicker to type,

Not if the K&R style was:
int func( a, b, c, d )
volatile unsigned char *a, *b, *c, *d;

I just tried this at home. K&R-style: 18.28 seconds. Modern style: 22.97
seconds. So yes, if you try hard, you can find counter-examples.
Similarly, if you pit a man against a horse in a foot-race, the man can
win if the race is sufficiently short (presumably because the horse has
more legs to sort out). The existence of counter-examples demonstrates not
that the proposition is universally false, but that it is not universally
true. I accept this.

{ .... }

(In fact, this argument was used by my C tutor at polytech
way back when, as to why he preferred K&R style).

In general, modern style is faster, especially when you choose descriptive
parameter names (upon which your C tutor should have been insisting). So
it's a poor argument.

 

[Barry Schwarz]

Hi,
I have a C file(add.c) in which i have a function called add.now
i want to call the same add function from another file sub.c .Can any1
tell how to do that...

add.now is not a legal name for a function but I assume you know how
to fix that. In addition to the information you have received about
how to deal with this issue in the source modules, you must also deal
with the implementation specific issue of how you tell your linker to
include the object module of the called function in the executable you
are building from sub.c.


Remove del for email

 

[Al Balmer]

Every time my compiler catches an error due to the
function call not matching the prototype, I reflect
for a moment on how much time I would have wasted
debugging if that error had not been reported.

For the last few years, I've had an ongoing "when I get time" project
to make around a million lines of pre-standard code compliant. With
very few exceptions, this process has revealed bugs in every program,
mostly in function calling and returns. (For example, defaulting a
function to return int and using the result, but writing just "return"
under some circumstances - the return value used is whatever happened
to be in the accumulator.)

Usually, when I talk about this to the support people, they recognize
an intermittent problem that's been reported for years

 

[Richard Harter]

For the last few years, I've had an ongoing "when I get time" project
to make around a million lines of pre-standard code compliant. With
very few exceptions, this process has revealed bugs in every program,
mostly in function calling and returns. (For example, defaulting a
function to return int and using the result, but writing just "return"
under some circumstances - the return value used is whatever happened
to be in the accumulator.)

Usually, when I talk about this to the support people, they recognize
an intermittent problem that's been reported for years

Go ahead, tell me that it was lint free.



Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
But the rhetoric of holistic harmony can generate into a kind of
dotty, Prince Charles-style mysticism. -- Richard Dawkins

 

[Al Balmer]

Go ahead, tell me that it was lint free.

If lint was available to them, they certainly didn't use it Years
ago, when I was briefly on a "Software QA" team, I suggested the use
of lint to a development manager. His reply was that he didn't want to
interfere with the "creativity" of his programmers. Some of them were
indeed creative.