A tired question?

[mdh]

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.

[pete]

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]

In article <72************ *************** *******@f1g2000 prb.googlegroup s.com>,
mdh <md**@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

[Mike Wahler]

"mdh" <md**@comcast.n etwrote in message
news:dd******** *************** ***********@w4g 2000prd.googleg roups.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]

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

mdh <md**@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]

On Jun 25, 8:35*pm, Peter Nilsson <[e-mail] .auwrote:

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

mdh *<m...@comcast. netwrote:

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]

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]

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]

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]

On Jun 25, 9:52*pm, Richard Heathfield <[e-mail].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.