problem in modular programing

[ashu]

lets look at the code given below
here i m trying to do mudular programming


/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);


when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

 

[Vladimir S. Oka]

lets look at the code given below
here i m trying to do mudular programming


/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);


when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

<OT>
Did you remember to tell your linker about mod1.o[bj]? The exact way
will depend on your toolchain.
</OT>

 

[osmium]

lets look at the code given below
here i m trying to do mudular programming


/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);


when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mood.exe

Looks OK to me. This kind of problem relates to your compiler setup and
this group doesn't discuss such things. So repost to a group dealing with
your compiler. But first,search the group you select for words such as make
file, IDE, project. Use the advanced search of Google groups. It is
unlikely you are the first person to have this problem.

 

[tmp123]

lets look at the code given below
here i m trying to do mudular programming


/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);


when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

Hi,

I do not see any error in your sources that can cause this problem.
It could be a problem with the way you compile and link. In particular,
check the order of the .c files.
If you are doing it with line commands or a makefile, please, post it.

Kind regards.

PS: To all readers: I known the compiler commands are OT, but it is the
best way to discard that error was in the source.

 

[pemo]

Hi,

I do not see any error in your sources that can cause this problem.
It could be a problem with the way you compile and link. In
particular, check the order of the .c files.
If you are doing it with line commands or a makefile, please, post it.

Kind regards.

PS: To all readers: I known the compiler commands are OT, but it is
the best way to discard that error was in the source.

Sounds like you're possibly using Visual C?

The code looks ok, btw, you don't need to include mod1.h in mod1.c - but
it's doing no harm.

If you've got the MS compiler set up to run from a command prompt, then this
should work ...

cl mmod.c mod1.c [output in mmod.exe]

Or, if you just want to use the linker ...

link mmod.obj mod1.obj [output in mmod.exe]

To set up the Microsoft compiler so that it works from a command prompt,
open a command prompt, navigate to ...\Microsoft Visual Studio\VC98\Bin and
run vcvars32

 

[Richard G. Riley]

lets look at the code given below
here i m trying to do mudular programming


/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);


when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

You are doing something wrong in the linker stage. Can you get the
compiler specific options to compile & link? Check them.

e.g using gcc under linux the following works fine

gcc -g mmod.c mod1.c
../a.out

(runs fine)

One thing : you dont need to include mod1.h into mod1.c : unless
someone can tell me a good reason why one should do so?

There will be a lot of people telling you this is OT for this NG and
they will be kind of right but stick with it - it can all be
confusing when you start Learn about make files. Use google.

 

[tmp123]

One thing : you dont need to include mod1.h into mod1.c : unless
someone can tell me a good reason why one should do so?

Verify prototypes?

 

[tmp123]

Sounds like you're possibly using Visual C?

O, no, me not: VC is too expensive for my bank account.
Was you trying to reply to the OP?

 

[Chris Dollin]

The code looks ok, btw, you don't need to include mod1.h in mod1.c - but
it's doing no harm.

You /should/ so include the .h in the .c; how else can you portably be
sure the compiler is going to detect mismatches between the declaration
and the definition?

 

[Richard G. Riley]

You /should/ so include the .h in the .c; how else can you portably be
sure the compiler is going to detect mismatches between the declaration
and the definition?

How does that affect including mod1.h into mod1.c?

 

[David Resnick]

How does that affect including mod1.h into mod1.c?

If you include it, it lets the compiler diagnose mismatches between
the definitions and declarations as was said above. Often then
clearer what is going on. Not "required", just a good idea.

Code standards in my group say to include your own header
*first*. That guarantees that anything needed by your header itself
(e.g. including <stdio.h> for FILE that is in a declaration) will be
there
assuming that your file can then compile -- it won't be masked
by inclusion of <stdio.h> in some other header above yours.
That prevents other users of the header (if any) from
having to figure out why your header isn't working.

-David

 

[CBFalconer]

.... snip ...

The code looks ok, btw, you don't need to include mod1.h in mod1.c
- but it's doing no harm.

Yes he should. That checks that the .h and .c files are compatible.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Richard G. Riley]

If you include it, it lets the compiler diagnose mismatches between
the definitions and declarations as was said above. Often then
clearer what is going on. Not "required", just a good idea.

I can buy into that. But does it give any real advantage considering
the users of that external do include the header? And then theres the
linking to hilite errors too.

Code standards in my group say to include your own header
*first*. That guarantees that anything needed by your header itself
(e.g. including <stdio.h> for FILE that is in a declaration) will be
there
assuming that your file can then compile -- it won't be masked
by inclusion of <stdio.h> in some other header above yours.
That prevents other users of the header (if any) from
having to figure out why your header isn't working.

Interesting. It was never a problem I came across but it makes some
sense. But I'm a little confused about what you mean by my *header*
needing things. I normally try to keep module headers as simple
declarations of that modules capabilities - the c module itself
includes the headers that it needs. If you follow me

 

[Pedro Graca]

pemo wrote:
[snip: ashu's example of modular programming and tmp123 answer]

you don't need to include mod1.h in mod1.c - but
it's doing no harm.

Isn't this a standard thing to do (I mean #include WHATEVER.h in
WHATEVER.c) to validate the header file?

If the implementation is changed without a corresponding change to the
header file, I assume the error will not be caught.

Test to validate my assumption:

tmp$ cat main.c utils.h utils.c
/* main.c */
#include <stdio.h>
#include "utils.h"
int main(void) {
long x = sqr(42);
printf("sqr(42) is %ld.\n\n", x);
return 0;
}

/* utils.h */
long sqr(int);

/* utils.c */
/* changed return type (was long) */
double sqr(int a) {
return (double)a*a; /* added cast to force double result */
}

tmp$ gcc -W -Wall -std=c89 -pedantic main.c utils.c
tmp$ ./a.out
sqr(42) is 0.

tmp$ sed -e 's/long/double/' -i utils.h
tmp$ gcc -W -Wall -std=c89 -pedantic main.c utils.c
tmp$ ./a.out
sqr(42) is 1764.

 

[Jordan Abel]

Interesting. It was never a problem I came across but it makes some
sense. But I'm a little confused about what you mean by my *header*
needing things. I normally try to keep module headers as simple
declarations of that modules capabilities - the c module itself
includes the headers that it needs. If you follow me

The header may need to include other headers that declare types which
are used for parameters or return values within the header (as with FILE
in the example)

 

[Fred Kleinschmidt]

lets look at the code given below
here i m trying to do mudular programming


/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

The above definition for the sqr() module is rather poor. The way you have
it, the compiler will probably multiply x*x as ints and then convert the
result to a long. Thus for any value of x greater than MAXINT/2 you will
likely get an overflow error.
Perhaps you really want
return (long)x * (long)x;

 

[Richard G. Riley]

The header may need to include other headers that declare types which
are used for parameters or return values within the header (as with FILE
in the example)

True, if this is the case. Special types I tend to keep in type
headers though. If, as in your example one needs to do that then I
have always tried to only include in those modules which need.

I'm interested in this other statement that the compiler needs it to check
the prototype against the declaration : while I can see that this
might be useful I've not (habitually) done it since I tend to export
the headers from the module anyway and also the linker raises any
issues. Is this bad practice? if it is, I'll put it right but it never
caused me a problem. Any light you can throw on this is appreciated.

 

[Ben Pfaff]

I can buy into that. But does it give any real advantage considering
the users of that external do include the header? And then theres the
linking to hilite errors too.

Headers include more than function prototypes. They often define
structures, enumerations, unions, macros, etc. If the .c file
wants to use those (and it normally does) then it'll need to
include the .h.

 

[pemo]

Yes he should. That checks that the .h and .c files are compatible.

Whether he *should* include, vs. *need* include the header is really a
different question. Personally, I think I *would* include the .h if it were
my code - however, I just wanted to point out that it isn't actually
required.

 

[David Resnick]

I'm interested in this other statement that the compiler needs it to check
the prototype against the declaration : while I can see that this
might be useful I've not (habitually) done it since I tend to export
the headers from the module anyway and also the linker raises any
issues. Is this bad practice? if it is, I'll put it right but it never
caused me a problem. Any light you can throw on this is appreciated.

Errors and warnings from the compiler/linker
depend on the compiler/linker. But consider this gcc example:

foo.c
int main(void)
{
return 0;
}
void foo(long quux)
{
}

bar.c
#include "foo.h"

void bar(void) {
foo();
}

foo.h
void foo(void);

temp(1327)$ gcc -Wall -o foo foo.c bar.c
temp(1327)$

No gripes. And foo the foo function will be reading garbage it seems.
Compare that to this foo.c (where foo.h and bar.c are unchanged)
#include "foo.h"

int main(void)
{
return 0;
}

void foo(long quux)
{
}

temp(1331)$ gcc -Wall -o foo foo.c bar.c
foo.c:9: conflicting types for `foo'
foo.h:1: previous declaration of `foo'

-David