problem in modular programing

[Richard G. Riley]

Re: problem in modular programing

On 2006-02-22, Jordan Abel <random832@gmai l.com> wrote:[color=blue]
> On 2006-02-22, Richard G. Riley <rgrileyevomer@ gmail.com> wrote:[color=green]
>> 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 :)[/color]
>
> 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)[/color]

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.


--
Remove evomer to reply

[Ben Pfaff]

Re: problem in modular programing

"Richard G. Riley" <rgrileyevomer@ gmail.com> writes:
[color=blue]
> On 2006-02-22, David Resnick <lndresnick@gma il.com> wrote:[color=green]
>> Richard G. Riley wrote:[color=darkred]
>>> On 2006-02-22, Chris Dollin <kers@hpl.hp.co m> wrote:
>>> > 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?[/color]
>>
>> 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.[/color]
>
> 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.[/color]

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.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Fred Kleinschmidt]

Re: problem in modular programing


"ashu" <riskyashish@ya hoo.com> wrote in message
news:1140620967 .232370.17040@o 13g2000cwo.goog legroups.com...[color=blue]
> 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) ));
> }[/color]

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;
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

[pemo]

Re: problem in modular programing

CBFalconer wrote:[color=blue]
> pemo wrote:[color=green]
>>[/color]
> ... snip ...[color=green]
>>
>> The code looks ok, btw, you don't need to include mod1.h in mod1.c
>> - but it's doing no harm.[/color]
>
> Yes he should. That checks that the .h and .c files are compatible.[/color]

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.

--
==============
*Not a pedant*
==============

[David Resnick]

Re: problem in modular programing

Richard G. Riley wrote:[color=blue]
> 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.
>
>
> --
> Remove evomer to reply[/color]

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

[Jordan Abel]

Re: problem in modular programing

On 2006-02-22, Richard G. Riley <rgrileyevomer@ gmail.com> wrote:[color=blue]
> On 2006-02-22, Jordan Abel <random832@gmai l.com> wrote:[color=green]
>> On 2006-02-22, Richard G. Riley <rgrileyevomer@ gmail.com> wrote:[color=darkred]
>>> 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 :)[/color]
>>
>> 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)[/color]
>
> 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.[/color]

Eh? what issues does the linker raise if the name is right but the type
is wrong?

[osmium]

Re: problem in modular programing

"Fred Kleinschmidt" writes:
[color=blue]
> "ashu" <riskyashish@ya hoo.com> wrote in message
> news:1140620967 .232370.17040@o 13g2000cwo.goog legroups.com...[color=green]
>> 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) ));
>> }[/color]
>
> 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;[/color]

Yes, I noticed that too. But the first step is to be able to compile, link,
and execute his program. I hope the OP can detect the fact that the pissing
war he has triggered has nothing at all to do with the problem *he* has. It
has to do with variants of his program that might have caused a failure to
compile. The OPs program does, in fact, compile.

[Ben Pfaff]

Re: problem in modular programing

Jordan Abel <random832@gmai l.com> writes:
[color=blue]
> Eh? what issues does the linker raise if the name is right but the type
> is wrong?[/color]

There's no reason the linker *can't* raise such issues, as far as
I know. The behavior is undefined. This gives the
implementation the latitude to, e.g., do C++-style name mangling
and thereby flag type mismatches at link time.
--
"I've been on the wagon now for more than a decade. Not a single goto
in all that time. I just don't need them any more. I don't even use
break or continue now, except on social occasions of course. And I
don't get carried away." --Richard Heathfield

[Richard G. Riley]

Re: problem in modular programing

On 2006-02-22, Jordan Abel <random832@gmai l.com> wrote:[color=blue]
> On 2006-02-22, Richard G. Riley <rgrileyevomer@ gmail.com> wrote:[color=green]
>> On 2006-02-22, Jordan Abel <random832@gmai l.com> wrote:[color=darkred]
>>> On 2006-02-22, Richard G. Riley <rgrileyevomer@ gmail.com> wrote:
>>>> 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)[/color]
>>
>> 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.[/color]
>
> Eh? what issues does the linker raise if the name is right but the type
> is wrong?[/color]

Hence my question : its not a problem I have come across. Common types
I tend to store seperate from the "x.h" header which represents the
"h.c" module.

I guess really my question is, and then I stand corrected, is it
really necessary to include function declarations into the module
where the functions are implemented? Its not something I have tended
to do with small standalone programs : bigger legacy system frequently
do this and I leave them untouched - and just as well if I'm missing
something really important here.


--
Remove evomer to reply

[Richard G. Riley]

Re: problem in modular programing

On 2006-02-22, Ben Pfaff <blp@cs.stanfor d.edu> wrote:[color=blue]
> "Richard G. Riley" <rgrileyevomer@ gmail.com> writes:
>[color=green]
>> On 2006-02-22, David Resnick <lndresnick@gma il.com> wrote:[color=darkred]
>>> Richard G. Riley wrote:
>>>> On 2006-02-22, Chris Dollin <kers@hpl.hp.co m> wrote:
>>>> > 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?
>>>
>>> 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.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

Hi Ben : I addressed in another post. My own convention has tended to
be to seperate such declarations from function prototypes and to
include those in the module specifically.
--
Remove evomer to reply

[Chris Torek]

Re: problem in modular programing

In article <463ti1F8727eU2 @individual.net >
Richard G. Riley <rgrileyevomer@ gmail.com> wrote:[color=blue]
>I guess really my question is, and then I stand corrected, is it
>really necessary to include function declarations into the module
>where the functions are implemented?[/color]

It is not *necessary*. It *is* a good idea.

A C compiler is not obliged to complain if we write the following, in
three separate files that build two translation units that build one
program:

/* main.c */
#include <stdio.h>
#include "bob.h"

int main(void) {
printf("bob() = %d\n", bob());
return 0;
}

/* bob.h */
int bob(void);

/* bob.c */
#include <string.h>
double bob(char *arg) {
if (strcmp(arg, "forty-two") == 0)
return 42.0;
return 3.1415926535897 932384626433832 795;
}

(Cut apart at comments, put into obvious files, and compile and see.)

Here main.c includes bob.h; bob.h lies, saying that bob() takes no
arguments and returns "int". Meanwhile, bob.c fails to include
bob.h. The compiler is not required to produce a diagnostic, and
most do not. The resulting executable (if we get one, and we usually
do) does not work right.

Had bob.c included bob.h, however, the compiler would have been
obligated to produce a diagnostic. We would have discovered, at
compile time, that bob.h lied about function bob(), and been given
a chance to fix the bug *before* it manifested.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

Re: problem in modular programing

tmp123 wrote:[color=blue]
>
> Richard G. Riley wrote:[color=green]
> >
> > 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?[/color]
>
> Verify prototypes?[/color]

That's the usual reason.

--
pete