Ahead of "main"?

[mdh]

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

[Malcolm McLean]

"mdh" <md**@comcast.n etwrote in message
news:11******** *************@h 2g2000hsg.googl egroups.com...

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.
Old C also had no prototypes. So if you put functions in reverse order of
hierarchy, the compiler could do additional checking of arguments. Nowadays
we should prototype all functions, so it doesn't matter where main() is
placed, though obviously it should be either the first or the last function
for readbility.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

mdh wrote:

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

Yes. If you use a function before declaring it, the
compiler makes assumptions about the arguments the function
takes and the value it returns. If the assumptions don't
match what the function actually does, you're in trouble.
(The latest compilers try to keep you out of trouble by
making no assumptions; instead, they issue error messages.)

Here's a point to ponder: A function definition -- the
type, name, arguments, and function body enclosed in { } --
not only defines the function, but also declares it (two
two-syllable verbs both beginning with DE, but they are not
the same). It is possible to declare a function without
defining it, by writing all the same things but omitting the
function body and putting a ; where the { }-enclosed stuff
would have been:

double trouble(int fireBurn, int cauldronBubble) ;

This tells the compiler about the arguments trouble() expects
and the type of value it returns, which is enough to allow
the compiler to invoke it properly (and to check for some
errors, like writing only one argument). Anytime after a
declaration line like this, you can call the function and
all will be well.

Still later, at some convenient point in the file, you
can supply the actual definition of the function:

double trouble(int fireBurn, int cauldronBubble)
{
if (fireBurn != 0)
return (double)cauldro nBubble / fireBurn;
else
return 42.0;
}

There are two main reasons (and some less pressing ones)
for wanting to write declaration-only lines. First, as you
move to larger programs you'll find yourself breaking them
up into separately-compiled files: Why should you copy the
entire body of trouble() into twenty different programs, when
you can compile it once in one file and then let all twenty
programs call it? To make this work, you need to write a
declaration-only line for trouble() that the other twenty
programs can use; the usual practice is to put this line in
a .h file the twenty programs can all #include.

A second reason pops up less frequently, but does occur
now and then. What if you have two functions macduff() and
macbeth(), and under some circumstances each of them calls
the other?

double macduff(int x) {
...
if (! i_am_thane)
y = macbeth(x);
...
}

double macbeth(int y) {
...
layOn = macduff(y + 42);
...
}

No matter which definition you place first, the other function's
definition will not have appeared by the time you get to its
call. The compiler will either make a wrong assumption about
the as-yet-undefined function, or will protest and sulk in a
corner. The solution is to write a declaration-only line for
one (or both) of the functions:

double macbeth(int); /* optional: omit arg names */

double macduff(int x) {
...
}

double macbeth(int y) {
...
}

--
Eric Sosman
es*****@acm-dot-org.invalid

[mdh]

On Apr 29, 1:41 pm, Eric Sosman <[e-mail] e:

mdh wrote:

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a ... diffference in declaring a function
within "main" or "ahead" of it.

>
Yes. If you use a function before declaring it,.....

Here's a point to ponder: A function definition --..... also declares it (two
two-syllable verbs both beginning with DE, but they are not
the same). It is possible to declare a function without
defining it,......

Thank you....as I do C more and more, I realize that words really
count.

>
There are two main reasons (and some less pressing ones)
for wanting to write declaration-only lines. First, as you
move to larger programs you'll find yourself breaking them
up into separately-compiled files:

>
A second reason pops up less frequently, but does occur
now and then. What if you have two functions macduff() and
macbeth(), and under some circumstances each of them calls
the other?

Thank you Eric.
So, if I understand you correctly, in my case for a small program, the
key seems to be to understand that a declaration needs to occur prior
to the function being called.
Where that declaration actually occurs (prior to main, or within main)
( under these limited circumstances) is of no consequence. However,
once one gets into the "real" world of C, this would be good
programming ( as you noted with seperate .h files), so I may as well
get used to practising good style!!

[mdh]

On Apr 29, 1:40 pm, "Malcolm McLean" <regniz...@btin ternet.comwrote :

>
Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.
Old C also had no prototypes. So if you put functions in reverse order of
hierarchy, the compiler could do additional checking of arguments. Nowadays
we should prototype all functions, so it doesn't matter where main() is
placed, though obviously it should be either the first or the last function
for readbility.

tks.

[Stephen Sprunk]

"mdh" <md**@comcast.n etwrote in message
news:11******** *************@h 2g2000hsg.googl egroups.com...

Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

In Standard C, functions cannot be declared "within" main(); these are
called nested functions and are implemented as an extension by some
compilers, but in general you should never use them. Therefore, the debate
is about whether to declare functions before or after main().

As a rule, you should declare all functions before you call them; I won't go
into the reasons why, as Eric did a good job of that. One style is to
define all other functions before main(), which also declares them. The
other is to declare all of your functions in a group near the beginning of
the source, and then you can define them in any order you want. The latter
style is effectively required when you move to multi-file projects, and the
standard practice is to put all of your function declarations in header (.h)
files so that each source file can simply #include the appropriate header
files and then use whatever functions are needed.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

mdh wrote:

On Apr 29, 1:41 pm, Eric Sosman <[e-mail] e:

>[...]
Here's a point to ponder: A function definition --..... also declares it (two
two-syllable verbs both beginning with DE, but they are not
the same). It is possible to declare a function without
defining it,......

[...]
So, if I understand you correctly, in my case for a small program, the
key seems to be to understand that a declaration needs to occur prior
to the function being called.
Where that declaration actually occurs (prior to main, or within main)
( under these limited circumstances) is of no consequence. However,
once one gets into the "real" world of C, this would be good
programming ( as you noted with seperate .h files), so I may as well
get used to practising good style!!

I think you are still confusing "declaratio n" and
"definition ." You should declare every function before
trying to call it (modern compilers change "should" to
"must"), but you can define the function wherever you
like. Since a definition is also a declaration (but not
vice-versa), if you define the function before calling
it you don't need a separate declaration. If you define
the function after calling it, or if you define it in a
separately-compiled file, you need a declaration prior
to the first call.

Eventually this will make sense. Trust me.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Barry Schwarz]

On Sun, 29 Apr 2007 21:40:00 +0100, "Malcolm McLean"
<re*******@btin ternet.comwrote :

>
"mdh" <md**@comcast.n etwrote in message
news:11******* **************@ h2g2000hsg.goog legroups.com...

>Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

It is certainly possible to declare a function within another.
Defining is prohibited but declaring is allowed. The drawback is that
the declaration has block scope and will not be visible to any other
function in the translation unit.

>Old C also had no prototypes. So if you put functions in reverse order of

Not always possible if function1 and function2 call each other as part
of a recursive algorithm.

>hierarchy, the compiler could do additional checking of arguments. Nowadays
we should prototype all functions, so it doesn't matter where main() is
placed, though obviously it should be either the first or the last function
for readbility.

Remove del for email

[Flash Gordon]

Stephen Sprunk wrote, On 29/04/07 22:35:

"mdh" <md**@comcast.n etwrote in message
news:11******** *************@h 2g2000hsg.googl egroups.com...

>Hi all,
Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?

In Standard C, functions cannot be declared "within" main(); these are
called nested functions and are implemented as an extension by some
compilers, but in general you should never use them.

Wrong. They can be *declared* within main or any other function, they
just cannot be *defined* in a function. A declaration says something
exists, a definition says what it is, the difference is important in C.

Therefore, the
debate is about whether to declare functions before or after main().

As a rule, you should declare all functions before you call them; I
won't go into the reasons why, as Eric did a good job of that. One
style is to define all other functions before main(), which also
declares them. The other is to declare all of your functions in a group
near the beginning of the source, and then you can define them in any
order you want. The latter style is effectively required when you move
to multi-file projects, and the standard practice is to put all of your
function declarations in header (.h) files so that each source file can
simply #include the appropriate header files and then use whatever
functions are needed.

Actually, you should not put *all* your function definitions in header
files, since generally there are some which should be local to a given
source file and declared static in that source file. I.e. you should
always limit visibility to the smallest unit that makes sense, since
then you don't have to look as far to see all of the usage.
--
Flash Gordon

[J. J. Farrell]

On Apr 29, 1:40 pm, "Malcolm McLean" <regniz...@btin ternet.comwrote :

"mdh" <m...@comcast.n etwrote in message

news:11******** *************@h 2g2000hsg.googl egroups.com...H i all,

Going quite methodically through K& R ( as some of you can attest
to!), I have never seen a big diffference in declaring a function
within "main" or "ahead" of it. Now, (p119, K&R II), the discussion
states that "functions "whatever" " should be declared ahead of
main.
Is there a good reason for this?
thanks.

Some early versions of C had local functions, declared within the function
that called them. The idea never caught on, and it is now not possible to
declare functions within main.

Nonsense. There is no problem declaring functions inside main or any
other function. The reasons why you may not want to do so are the
scoping rules, since the declaration would only be visible within the
same block as the declaration. On the other hand, that's perhaps
exactly why you would want to do it on the few occasions where it
makes sense to do so.