A tired question?

**pete** · Jun 27 '08, 07:42 PM

Re: A tired question?

mdh wrote:

I have looked this up in the FAQ, and still do not have a nice
understanding of it.
>
If I have defined a function in foo.c, and if, for the sake of
argument have foo.h contain that function's declaration, and if , as
one of the answers to a similar question was "All definitions are also
declarations!" then does one need to use "# include foo.h" in foo.c?

You can usually get away without it,
but "getting away with something" isn't good coding.

If you # include foo.h" in foo.c,
then the compiler will check that the function types match.

--
pete

**dj3vande@csclub.uwaterloo.ca.invalid** · Jun 27 '08, 07:42 PM

Re: A tired question?

In article <72164536-3dfd-4066-a4ec-46825b5cbe01@f1 g2000prb.google groups.com>,
mdh <mdeh@comcast.n etwrote:

>I have looked this up in the FAQ, and still do not have a nice
>understandin g of it.
>
>If I have defined a function in foo.c, and if, for the sake of
>argument have foo.h contain that function's declaration, and if , as
>one of the answers to a similar question was "All definitions are also
>declarations !" then does one need to use "# include foo.h" in foo.c?

It's not strictly necessary (since the definition of the function does
serve as the declaration there), but it's still a good idea to do so,
because that lets the compiler make sure that the declaration in foo.h
matches what's in foo.c.
The compiler can (and in many common cases is required to) complain if
it sees two incompatible declarations of the same function or variable
in the same translation unit, but if you don't #include "foo.h" from
foo.c, it won't ever see both versions at the same time[1], so it won't
have the opportunity to do that.

Diagnosable errors are ALWAYS better than silent undefined behavior,
and silent undefined behavior is what you end up getting if you call a
function that was declared (to the calling code) differently than it
was defined.

dave

[1] It's still quite possible for a sufficiently clever compiler to
arrange for this to be checked, and there are also code checking
tools (lint is the canonical example) that specifically look for
incompatible declarations in places where the compiler is unlikely
to see them, but it does take rather more effort.

--
Dave Vandervies dj3vande at eskimo dot com

Insult your lusers, not random swaths of your fellow sysadmins.
--Alan J Rosenthal in the scary devil monastery

**mdh** · Jun 27 '08, 07:42 PM

Re: A tired question?

On Jun 25, 7:51 pm, dj3va...@csclub .uwaterloo.ca.i nvalid wrote:

In article <72164536-3dfd-4066-a4ec-46825b5cb...@f1 g2000prb.google groups.com>,
>
>

If I have defined a function in foo.c, and .......have foo.h contain that function's declaration, and ...."All definitions are also
declarations!" then does one need to use "# include foo.h" in foo.c?

>
It's not strictly necessary (since the definition of the function does
serve as the declaration there), but it's still a good idea to do so,
because that lets the compiler make sure that the declaration in foo.h
matches what's in foo.c.
The compiler can (and in
Diagnosable errors are ALWAYS better than silent undefined behavior....... ...
>

Not sure if this is straying to the philosophical.. .. It is clearly a
good check, almost having the compiler ask "Are you really sure that
the function definition is correctly written?" if it can check the
format against a declaration. Other than that...is there something in
the C language that sets it up this way? ( For instance, as far as
variables are concerned, K&R say (Page 40) "All variables must be
declared before use,...). I have not found any language in K&R that
make such a specific statement about functions. Sorry is this sounds a
little dumb, if so, it's me not getting it.

**Mike Wahler** · Jun 27 '08, 07:42 PM

Re: A tired question?

"mdh" <mdeh@comcast.n etwrote in message
news:dd90dfe6-e7e8-4c59-898a-111e70df93b7@w4 g2000prd.google groups.com...

Not sure if this is straying to the philosophical.. .. It is clearly a
good check, almost having the compiler ask "Are you really sure that
the function definition is correctly written?" if it can check the
format against a declaration. Other than that...is there something in
the C language that sets it up this way? ( For instance, as far as
variables are concerned, K&R say (Page 40) "All variables must be
declared before use,...). I have not found any language in K&R that
make such a specific statement about functions. Sorry is this sounds a
little dumb, if so, it's me not getting it.

See p.217-218 (section A.8.6.3, especially the smaller-print paragraph
near the end of p 218.)

..

-Mike

**Peter Nilsson** · Jun 27 '08, 07:42 PM

Re: A tired question?

dj3va...@csclub .uwaterloo.ca.i nvalid wrote:

mdh <mdeh@comcast.n etwrote:

If I have defined a function in foo.c, and if, for the sake
of argument have foo.h contain that function's declaration,
and if , as one of the answers to a similar question was
"All definitions are also declarations!" then does one
need to use "# include foo.h" in foo.c?

>
It's not strictly necessary (since the definition of the function
does serve as the declaration there), but it's still a good idea
to do so, because that lets the compiler make sure that the
declaration in foo.h matches what's in foo.c.

For full value, make your declarations prototypes.

--
Peter

**mdh** · Jun 27 '08, 07:42 PM

Re: A tired question?

On Jun 25, 8:35 pm, Peter Nilsson <ai...@acay.com .auwrote:

dj3va...@csclub .uwaterloo.ca.i nvalid wrote:

mdh <m...@comcast.n etwrote:

If I have defined a function in foo.c, and if, for the sake
of argument have foo.h contain that function's declaration,
and if , as one of the answers to a similar question was
"All definitions are also declarations!" then does one
need to use "# include foo.h" in foo.c?

>

It's not strictly necessary (since the definition of the function
does serve as the declaration there), but it's still a good idea
to do so, because that lets the compiler make sure that the
declaration in foo.h matches what's in foo.c.

>
For full value, make your declarations prototypes.
>
--
Peter

Thank you all....I am sure with the clarity of time, it will be more
apparent to me.

**santosh** · Jun 27 '08, 07:42 PM

Re: A tired question?

mdh wrote:

I have looked this up in the FAQ, and still do not have a nice
understanding of it.
>
If I have defined a function in foo.c, and if, for the sake of
argument have foo.h contain that function's declaration, and if , as
one of the answers to a similar question was "All definitions are also
declarations!" then does one need to use "# include foo.h" in foo.c?
>
Thanks in advance.

Besides what the others have already said, note that you will have to
have a declaration at the top of foo.c, if the some function or
functions call the function in question and appear before that function
in the translation unit. And one way to place a declaration at the top
of foo.c is to include foo.h of course.

**mdh** · Jun 27 '08, 07:42 PM

Re: A tired question?

On Jun 25, 9:09 pm, santosh <santosh....@gm ail.comwrote:

mdh wrote:

I have looked this up in the FAQ, and still do not have a nice
understanding of it.

>

Besides what the others have already said, note that you will have to
have a declaration at the top of foo.c, if the some function or
functions call the function in question and appear before that function
in the translation unit. And one way to place a declaration at the top
of foo.c is to include foo.h of course.

So, is this then correct.
If I am calling, lets say f(), which is defined in foo.c, from main,
then I only need to #include foo.h in main? and not in foo.c? Or,
only include foo.h in foo.c and not in main? I have been including
them in both ( ie main and foo.c) and it seems duplicative and
unnecessary?

**Richard Heathfield** · Jun 27 '08, 07:42 PM

Re: A tired question?

mdh said:

On Jun 25, 9:09 pm, santosh <santosh....@gm ail.comwrote:

>mdh wrote:

I have looked this up in the FAQ, and still do not have a nice
understanding of it.

>>

>

>Besides what the others have already said, note that you will have to
>have a declaration at the top of foo.c, if the some function or
>functions call the function in question and appear before that function
>in the translation unit. And one way to place a declaration at the top
>of foo.c is to include foo.h of course.

>
So, is this then correct.
If I am calling, lets say f(), which is defined in foo.c, from main,
then I only need to #include foo.h in main? and not in foo.c? Or,
only include foo.h in foo.c and not in main? I have been including
them in both ( ie main and foo.c) and it seems duplicative and
unnecessary?

Because you need to call foo() from main.c, you need a declaration for
foo() in main.c's scope, right?

Because you might need, one day (perhaps tomorrow or later on this
afternoon), to call foo() from bar.c, it is convenient to have the foo()
declaration in a header, so that main.c and bar.c can just #include it
rather than you have to type a separate declaration for each. Bear in mind
that the minimal work saving for this becomes rather more significant when
you realise that foo() is really just a shorthand for foo_create(),
foo_destroy(), foo_insert(), foo_delete(), foo_sort(), foo_enquire(),
foo_test(), foo_process(), foo_print(), and whatever other fooish notions
one might entertain. Suddenly, the header starts to look attractive,
right?

Because you might, one day Real Soon Now, modify the implementation of
foo(), it makes sense to make sure that main.c has the right declarations,
right?

Because #including foo.h into foo.c will have the effect of forcing the
compiler to check that the declarations in foo.h match the declarations in
foo.c, #including foo.h into foo.c suddenly starts to look attractive
here, too, right?

--
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

**mdh** · Jun 27 '08, 07:42 PM

Re: A tired question?

On Jun 25, 9:52 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

mdh said:
>
>
>

On Jun 25, 9:09 pm, santosh <santosh....@gm ail.comwrote:

mdh wrote:
I have looked this up in the FAQ, and still do not have a nice
understanding of it.

>

Besides what the others have already said, note that you will have to
have a declaration at the top of foo.c, if the some function or
functions call the function in question and appear before that function
in the translation unit. And one way to place a declaration at the top
of foo.c is to include foo.h of course.

>

So, is this then correct.
If I am calling, lets say f(), which is defined in foo.c, from main,
then I only need to #include foo.h in main? and not in foo.c? Or,
only include foo.h in foo.c and not in main? I have been including
them in both ( ie main and foo.c) and it seems duplicative and
unnecessary?

>
Because you need to call foo() from main.c, you need a declaration for
foo() in main.c's scope, right?
>
Because you might need, one day (perhaps tomorrow or later on this
afternoon), to call foo() from bar.c, it is convenient to have the foo()
declaration in a header, so that main.c and bar.c can just #include it
rather than you have to type a separate declaration for each. Bear in mind
that the minimal work saving for this becomes rather more significant when
you realise that foo() is really just a shorthand for foo_create(),
foo_destroy(), foo_insert(), foo_delete(), foo_sort(), foo_enquire(),
foo_test(), foo_process(), foo_print(), and whatever other fooish notions
one might entertain. Suddenly, the header starts to look attractive,
right?
>
Because you might, one day Real Soon Now, modify the implementation of
foo(), it makes sense to make sure that main.c has the right declarations,
right?
>
Because #including foo.h into foo.c will have the effect of forcing the
compiler to check that the declarations in foo.h match the declarations in
foo.c, #including foo.h into foo.c suddenly starts to look attractive
here, too, right?
>
--
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

Thank you Richard.

**rahul** · Jun 27 '08, 07:42 PM

Re: A tired question?

On Jun 26, 9:25 am, mdh <m...@comcast.n etwrote:

On Jun 25, 9:09 pm, santosh <santosh....@gm ail.comwrote:
>

mdh wrote:

I have looked this up in the FAQ, and still do not have a nice
understanding of it.

>

Besides what the others have already said, note that you will have to
have a declaration at the top of foo.c, if the some function or
functions call the function in question and appear before that function
in the translation unit. And one way to place a declaration at the top
of foo.c is to include foo.h of course.

>
So, is this then correct.
If I am calling, lets say f(), which is defined in foo.c, from main,
then I only need to #include foo.h in main? and not in foo.c? Or,
only include foo.h in foo.c and not in main? I have been including
them in both ( ie main and foo.c) and it seems duplicative and
unnecessary?

/* BEGIN foo.h */
#ifndef _FOO_H
#define _FOO_H
void f(void);
#endif

/* BEGIN foo.c */
#include "foo.h"
void f(void) {
/* implementation */
}

/* BEGIN bar.c */
#include "foo.h"

int
main(void) {
f();
return 0;
}

Its not necessary to include foo.h in foo.c but it's a good practice.
The inclusion is not duplicative. In standard C, prototype of a
function is required before you can invoke it if the definition has
not been encountered. In foo.c, you are defining it, so the prototype
may be ommited. But it ensures type checking. If you do not include
the foo.h, it may be possible that you add an extra parameter in f()
in foo.c and forget to do that in foo.h.

The inclusion guarantees proper checking by the compiler. Before
standardization , if the prototype of a function is not specified
before invocation, the function was assumed to be returning int and
taking unspecified parameters.

**Richard Heathfield** · Jun 27 '08, 07:42 PM

Re: A tired question?

rahul said:

<snip>

/* BEGIN foo.h */
#ifndef _FOO_H
#define _FOO_H

You just invaded the implementation' s namespace. The simplest way to avoid
this particular breach is to avoid starting your identifiers with
underscores. (If you also avoid E, str, mem, and is, I think you're pretty
safe all round.)

One common convention is to use H_FOO.

<snip>

--
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

**CBFalconer** · Jun 27 '08, 07:42 PM

Re: A tired question?

mdh wrote:

santosh <santosh....@gm ail.comwrote:

>mdh wrote:
>>

>>I have looked this up in the FAQ, and still do not have a nice
>>understandi ng of it.

>>
>Besides what the others have already said, note that you will
>have to have a declaration at the top of foo.c, if the some
>function or functions call the function in question and appear
>before that function in the translation unit. And one way to
>place a declaration at the top of foo.c is to include foo.h of
>course.

>
So, is this then correct.
If I am calling, lets say f(), which is defined in foo.c, from
main, then I only need to #include foo.h in main? and not in
foo.c? Or, only include foo.h in foo.c and not in main? I have
been including them in both ( ie main and foo.c) and it seems
duplicative and unnecessary?

You need to realize that the purpose of foo.h file is to export
such items as you wish to export from foo.c to some other file.
This enables linking. The reason to include foo.h in the foo.c
compilation is to ensure that foo.h agrees properly with foo.c.

Headers have a much more serious purpose than simply separating
'header items' from the actual .c files.

Suitable use of the static word, and omission of items from the
foo.h file, will keep them hidden. If you don't modify foo.h you
can nevertheless modify foo.c as much as you want. To get the
changes into other programs will then require relinking, but the
only thing needing recompilation is foo.c. If you accidentally
modify something that requires a foo.h change, compilation with the
old foo.h will usually generate warnings and errors.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

** Posted from http://www.teranews.com **

**mdh** · Jun 27 '08, 07:42 PM

Re: A tired question?

>
The inclusion guarantees proper checking by the compiler. Before
standardization , if the prototype of a function is not specified
before invocation, the function was assumed to be returning int and
taking unspecified parameters.

Good point..thanks

A tired question?

A tired question?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment