Function prototypes

[Steph Barklay]

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

[Al Balmer]

On Thu, 23 Aug 2007 01:12:41 +0200 (CEST), Steph Barklay
<do**@spam.mewrote:

>Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Is this for real? I find it hard to believe that any such teacher
exists. If this is not a troll, you should, if at all possible, enroll
in another class with a different teacher. If this is not possible,
ask your teacher to monitor this newsgroup for a while.

If that doesn't work, I don't know what to suggest. Probably you
should drop the course, and study C on your own.

--
Al Balmer
Sun City, AZ

[Old Wolf]

On Aug 23, 11:40 am, Richard Heathfield <[e-mail]:

Your teacher is 100% wrong, brain-dead, and beyond redemption. Only
fools put code in headers.

Only fools and C++ programmers ;)

[Keith Thompson]

Steph Barklay <do**@spam.mewrites:

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Your teacher is very very very very very wrong.

Ask him to explain section 4.5 of K&R2 (that's Kernighan & Ritchie,
_The C Programming Language_, 2nd Edition) (it starts on page 81),
which absolutely contradicts your teacher's claims.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Old Wolf said:

On Aug 23, 11:40 am, Richard Heathfield <[e-mail]:

>Your teacher is 100% wrong, brain-dead, and beyond redemption. Only
fools put code in headers.

Only fools and C++ programmers ;)

But you repeat yourself. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[user923005]

On Aug 22, 4:12 pm, Steph Barklay <[e-mail]:

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Your teacher is criminally insane. Notify the authorities right away.

On the other hand, this is my evil handiwork:

#ifdef _MSC_VER
#include <windows.h>
#else
#include <unistd.h>
#endif

#include "searchr.c"
#include "search.c"
#include "thread.c"
#include "searchmp.c"
#include "repeat.c"
#include "next.c"
#include "nexte.c"
#include "nextr.c"
#include "history.c"
#include "quiesce.c"
#include "evaluate.c"
#include "movgen.c"
#include "make.c"
#include "unmake.c"
#include "hash.c"
#include "attacks.c"
#include "swap.c"
#include "boolean.c"
#include "utility.c"
#include "valid.c"
#include "probe.c"
#include "book.c"
#include "analyze.c"
#include "annotate.c"
#include "bench.c"
#include "data.c"
#ifndef _MSC_VER
#include "dgt.c"
#endif
#include "drawn.c"
#include "edit.c"
#include "epd.c"
#include "epdglue.c"
#include "evtest.c"
#include "init.c"
#include "input.c"
#include "interupt.c"
#include "iterate.c"
#include "learn.c"
#include "main.c"
#include "option.c"
#include "output.c"
#include "ponder.c"
#include "preeval.c"
#include "resign.c"
#include "root.c"
#include "setboard.c"
#include "test.c"
#include "time.c"
#include "validate.c"

On the other hand, each of those files has headers with prototypes and
there are headers with prototypes at the top even of this file.
Some compilers can inline more aggressively if you make every file
available as a single giant block of source code.

[Stephen Sprunk]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:ct******************************@bt.com...

Your teacher is 100% wrong, brain-dead, and beyond redemption.
Only fools put code in headers.

99% wrong; there are valid reasons for code in headers, such as
function-like macros or static inline functions. However, I doubt that the
teacher was thinking about those things.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Steph Barklay wrote:

>
Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Either the teacher, or your interpretation of his words, are
totally balmy.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Eric Sosman]

Steph Barklay wrote:

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes.
[...]

Two possibilities occur to me. First, you may have
misunderstood what the teacher said (the blame for this
could lie on either side, or on both). It would be a
good idea to discuss this matter with the teacher to clear
up any possible misunderstanding.

Second, you may not have misunderstood at all, and
the teacher may actually have made this assertion. If so,
I recommend you drop the course: a teacher who utters this
sort of nonsense (other than as a pedagogic device intended
to elicit push-back, which really falls under Possibility 1)
is ignorant of his or her subject. This person may be able
to teach you something useful, but will teach you a lot of
nonsense along with it and leave you the task of separating
the one from the other unassisted.

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

[pete]

Steph Barklay wrote:

>
Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes.

That implies, or very nearly implies,
that professional programmers don't write C programs
with more than one file of source code.

It also suggests that your teacher has never
written a C program with more than one file of source code,
and thus is a neophyte programmer.
How old is this kid?

I hope that you're mistaken about what he said.

This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes.
The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c,
so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int.
I tried to explain this to my teacher,
but the answer he gave me is that I should just put the
whole function within the header file
and not have any other *.c files.
I haven't seen anyone put whole functions
within header files before. Am I wrong about this

No.

or is my teacher wrong?

He absolutely does not understand what header files are for,
and is giving very strong indications
that he has no experience with multifile C programs.

Thank you.

Again, I very much hope that you have misunderstood what he meant.

--
pete

[osmium]

"Steph Barklay" <do**@spam.mewrote in message
news:sl*******************@nospam.invalid...

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Your instructor is pathetic. He is talking about little toy programs, the
kind you write in the very class you are enrolled in. My guess is that he
has never seen the code for a real program in his entire life.

[Army1987]

On Wed, 22 Aug 2007 19:42:38 -0700, osmium wrote:

>
"Steph Barklay" <do**@spam.mewrote in message
news:sl*******************@nospam.invalid...

>Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Your instructor is pathetic. He is talking about little toy programs, the
kind you write in the very class you are enrolled in. My guess is that he
has never seen the code for a real program in his entire life.

I can't see any use in doing so in even the smallest program. (If
a program is *really* a little toy program, there is no real
reason to split it across several source files, either, unless to
teach how that is done; but I think that teaching to do that badly
is worse that not to teach it at all.)
--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Army1987]

On Wed, 22 Aug 2007 17:21:03 -0700, user923005 wrote:

On Aug 22, 4:12 pm, Steph Barklay <[e-mail]:

>Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Your teacher is criminally insane. Notify the authorities right away.

On the other hand, this is my evil handiwork:

#ifdef _MSC_VER
#include <windows.h>
#else
#include <unistd.h>
#endif

#include "searchr.c"
#include "search.c"

[snip enormous list]

#include "time.c"
#include "validate.c"

On the other hand, each of those files has headers with prototypes and
there are headers with prototypes at the top even of this file.
Some compilers can inline more aggressively if you make every file
available as a single giant block of source code.

At least their name ends with .c, so that one will know that extra
care shall be taken not to define anything twice.
--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Ravishankar S]

#ifdef _MSC_VER

#include <windows.h>
#else
#include <unistd.h>
#endif

#include "searchr.c"
#include "search.c"
#include "thread.c"
#include "searchmp.c"
#include "repeat.c"
#include "next.c"
#include "nexte.c"
#include "nextr.c"
#include "history.c"
#include "quiesce.c"
#include "evaluate.c"
#include "movgen.c"
#include "make.c"
#include "unmake.c"
#include "hash.c"
#include "attacks.c"
#include "swap.c"
#include "boolean.c"
#include "utility.c"
#include "valid.c"
#include "probe.c"
#include "book.c"
#include "analyze.c"
#include "annotate.c"
#include "bench.c"
#include "data.c"
#ifndef _MSC_VER
#include "dgt.c"
#endif
#include "drawn.c"
#include "edit.c"
#include "epd.c"
#include "epdglue.c"
#include "evtest.c"
#include "init.c"
#include "input.c"
#include "interupt.c"
#include "iterate.c"
#include "learn.c"
#include "main.c"
#include "option.c"
#include "output.c"
#include "ponder.c"
#include "preeval.c"
#include "resign.c"
#include "root.c"
#include "setboard.c"
#include "test.c"
#include "time.c"
#include "validate.c"
Some compilers can inline more aggressively if you make every file
available as a single giant block of source code.

just a little off topic:
Would the compilation also be faster if all headers were included in a gaint
header file ?

[Richard Heathfield]

osmium said:

<snip>

I almost always write such programs "Pascal style", which obviates the
prototypes.

No, not really. A prototype is a function declaration that lists the
types of its parameters. For function definitions /not/ to do this,
they must either be written K&R style or with empty parentheses. Both
of these styles are very rare nowadays. It is almost certain that you
are in fact using prototypes, even when programming "Pascal style".

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[osmium]

"Richard Heathfield" writes:

osmium said:

<snip>

>I almost always write such programs "Pascal style", which obviates the
prototypes.

No, not really. A prototype is a function declaration that lists the
types of its parameters. For function definitions /not/ to do this,
they must either be written K&R style or with empty parentheses. Both
of these styles are very rare nowadays. It is almost certain that you
are in fact using prototypes, even when programming "Pascal style".

As you should know by now, I am not a big fan of using word games in
discussions involving newbies.

[Richard Heathfield]

osmium said:

"Richard Heathfield" writes:

>osmium said:

<snip>

>>I almost always write such programs "Pascal style", which obviates
the prototypes.

No, not really. A prototype is a function declaration that lists the
types of its parameters. For function definitions /not/ to do this,
they must either be written K&R style or with empty parentheses. Both
of these styles are very rare nowadays. It is almost certain that you
are in fact using prototypes, even when programming "Pascal style".

As you should know by now, I am not a big fan of using word games in
discussions involving newbies.

As you should know by now, using proper terminology in the proper way is
not a matter of word games, but a matter of correctness.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard]

"osmium" <r1********@comcast.netwrites:

"Richard Heathfield" writes:

>osmium said:

<snip>

>>I almost always write such programs "Pascal style", which obviates the
prototypes.

No, not really. A prototype is a function declaration that lists the
types of its parameters. For function definitions /not/ to do this,
they must either be written K&R style or with empty parentheses. Both
of these styles are very rare nowadays. It is almost certain that you
are in fact using prototypes, even when programming "Pascal style".

As you should know by now, I am not a big fan of using word games in
discussions involving newbies.

And as you should know, *any* thread that Mr Heathfield contributes to
descends to just that.

I still his recall "there is no such thing as a global variable in C" blather.

[Kenneth Brody]

Keith Thompson wrote:

>
Steph Barklay <do**@spam.mewrites:

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This

[...]

to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Your teacher is very very very very very wrong.

Ask him to explain section 4.5 of K&R2 (that's Kernighan & Ritchie,
_The C Programming Language_, 2nd Edition) (it starts on page 81),
which absolutely contradicts your teacher's claims.

"And what makes those guys such experts at C programming?" :-) :-)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

pete wrote:

>
Steph Barklay wrote:

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes.

That implies, or very nearly implies,
that professional programmers don't write C programs
with more than one file of source code.

.... nor use any standard library functions other than the non-varadic
ones that return int. (Bye bye malloc and printf, among others.)

It also suggests that your teacher has never
written a C program with more than one file of source code,
and thus is a neophyte programmer.
How old is this kid?

Even neophytes can #include <stdio.hon day one.

I hope that you're mistaken about what he said.

I think/hope "ditto" applies to everyone reading clc. (Though I
wouldn't hold my breath waiting for the answer to that.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

"osmium" <r1********@comcast.netwrites:

"Richard Heathfield" writes:

>osmium said:
<snip>

>>I almost always write such programs "Pascal style", which obviates the
prototypes.

No, not really. A prototype is a function declaration that lists the
types of its parameters. For function definitions /not/ to do this,
they must either be written K&R style or with empty parentheses. Both
of these styles are very rare nowadays. It is almost certain that you
are in fact using prototypes, even when programming "Pascal style".

As you should know by now, I am not a big fan of using word games in
discussions involving newbies.

I see no word games here. The word "prototype" has a very specific
meaning, and it includes both standalone function declarations:
void func(int);
and full function definitions:
void func(int arg) { /* ... */ }

The term is used to distinguish declarations that include argument
types (a feature introduced in ANSI C89, borrowed from early C++) from
the older K&R-style declarations that do not include argument types.

Do you have some reason to assume that the original poster was using
the term in the same narrow sense in which you were using it?

If we're using the term "prototype" in some sense other than the way
the standard defines it, then *somebody* should say so explicitly.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[user923005]

On Aug 23, 4:32 am, "Ravishankar S" <[e-mail]>
wrote:

#ifdef _MSC_VER
#include <windows.h>
#else
#include <unistd.h>
#endif

#include "searchr.c"
#include "search.c"
#include "thread.c"
#include "searchmp.c"
#include "repeat.c"
#include "next.c"
#include "nexte.c"
#include "nextr.c"
#include "history.c"
#include "quiesce.c"
#include "evaluate.c"
#include "movgen.c"
#include "make.c"
#include "unmake.c"
#include "hash.c"
#include "attacks.c"
#include "swap.c"
#include "boolean.c"
#include "utility.c"
#include "valid.c"
#include "probe.c"
#include "book.c"
#include "analyze.c"
#include "annotate.c"
#include "bench.c"
#include "data.c"
#ifndef _MSC_VER
#include "dgt.c"
#endif
#include "drawn.c"
#include "edit.c"
#include "epd.c"
#include "epdglue.c"
#include "evtest.c"
#include "init.c"
#include "input.c"
#include "interupt.c"
#include "iterate.c"
#include "learn.c"
#include "main.c"
#include "option.c"
#include "output.c"
#include "ponder.c"
#include "preeval.c"
#include "resign.c"
#include "root.c"
#include "setboard.c"
#include "test.c"
#include "time.c"
#include "validate.c"
Some compilers can inline more aggressively if you make every file
available as a single giant block of source code.

just a little off topic:
Would the compilation also be faster if all headers were included in a gaint
header file ?

No, probably slower -- a lot slower.
The above technique does not speed up compilation (generally compiles
run much slower). On some systems, it will increase the executable
speed of the binary.

[user923005]

On Aug 23, 3:39 am, Army1987 <[e-mail]:

On Wed, 22 Aug 2007 19:42:38 -0700, osmium wrote:

"Steph Barklay" <[e-mail] in message
news:sl*******************@nospam.invalid...

Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function prototypes. This
kind of bugged me, because from other people's code that I've seen in
the past, almost all of them use function prototypes. The following also
bugged me. Let's say you have a file called main.c with only the main
function, and includes hello.h, to use functions within hello.c. So
hello.h should contain prototypes for the functions in hello.c, so when
main.c is compiled, there won't be any warnings. If there aren't any
prototypes in the header file, my compiler would assume the function
called with main() is extern and returns an int. I tried to explain this
to my teacher, but the answer he gave me is that I should just put the
whole function within the header file and not have any other *.c files.
I haven't seen anyone put whole functions within header files before. Am
I wrong about this or is my teacher wrong? Thank you.

Your instructor is pathetic. He is talking about little toy programs, the
kind you write in the very class you are enrolled in. My guess is that he
has never seen the code for a real program in his entire life.

I can't see any use in doing so in even the smallest program. (If
a program is *really* a little toy program, there is no real
reason to split it across several source files, either, unless to
teach how that is done; but I think that teaching to do that badly
is worse that not to teach it at all.)

I must agree with Army1987 here.
It seems likely that even the most trivial of programs will want to
print something to standard output.
If there is anything more than a simple character string that could
utilize puts(), then printf() is required which is a varadic
function. Calling a varadic function without the presence of a
prototype causes undefined behavior.
So even with the most trivial of toy programs, function prototypes are
basically a necessity.

[osmium]

"Keith Thompson" writes:

"osmium" <r1********@comcast.netwrites:

>"Richard Heathfield" writes:

>>osmium said:
<snip>

I almost always write such programs "Pascal style", which obviates the
prototypes.

No, not really. A prototype is a function declaration that lists the
types of its parameters. For function definitions /not/ to do this,
they must either be written K&R style or with empty parentheses. Both
of these styles are very rare nowadays. It is almost certain that you
are in fact using prototypes, even when programming "Pascal style".

As you should know by now, I am not a big fan of using word games in
discussions involving newbies.

I see no word games here. The word "prototype" has a very specific
meaning, and it includes both standalone function declarations:
void func(int);
and full function definitions:
void func(int arg) { /* ... */ }

The term is used to distinguish declarations that include argument
types (a feature introduced in ANSI C89, borrowed from early C++) from
the older K&R-style declarations that do not include argument types.

Do you have some reason to assume that the original poster was using
the term in the same narrow sense in which you were using it?

Of course I have such a reason. The instructor's programs wouldn't work
otherwise, all he could do is write functions that returned an int or
returned nothing. I have already agreed the instructor shouldn't have said
what he said. What do you want, blood?

Why burden the OP in this thread with a bunch of esoterica on the fine
points of the standard? Presumably he wants to learn to write programs, not
how to write or interpret standards for a programming language. I talk to
people every day who have a poor grasp of English, yet we manage to muddle
though and I end up getting my hamburger..

[Eric Sosman]

osmium wrote On 08/23/07 17:28,:

[...]
Why burden the OP in this thread with a bunch of esoterica on the fine
points of the standard?

Because his instructor has confused him by misusing
a technical term. Resolving the confusion by explaining
the misuse is not imposing a burden.

[...] I talk to
people every day who have a poor grasp of English, yet we manage to muddle
though and I end up getting my hamburger..

Or your jelly-filled doughnut, as the case may be.

--
Er*********@sun.com

[Keith Thompson]

"osmium" <r1********@comcast.netwrites:
[...]

Of course I have such a reason. The instructor's programs wouldn't work
otherwise, all he could do is write functions that returned an int or
returned nothing. I have already agreed the instructor shouldn't have said
what he said. What do you want, blood?

Why burden the OP in this thread with a bunch of esoterica on the fine
points of the standard? Presumably he wants to learn to write programs, not
how to write or interpret standards for a programming language.

[...]

Presumably he wants to write and talk about programs as well as
writing them. In doing so, it's going to be essential to understand
what technical words and phrases actually mean. One such word is
"prototype".

What if the instructor said not to use "functions", but actually meant
that each function must return a non-void result? Would you complain
if I pointed out that the word "function" is being misused? Or does
each person get to decide what a word means?

Now that we all know what the word "prototype" actually means, can we
drop this?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Kenneth Brody wrote:

>
pete wrote:

Steph Barklay wrote:

>
Hi, I'm currently taking a data structures course in C,
and my teacher
said that function prototypes are
not allowed in any of our code. He
also said that no professional
programmers use function prototypes.

That implies, or very nearly implies,
that professional programmers don't write C programs
with more than one file of source code.

... nor use any standard library functions other than the non-varadic
ones that return int. (Bye bye malloc and printf, among others.)

It also suggests that your teacher has never
written a C program with more than one file of source code,
and thus is a neophyte programmer.
How old is this kid?

Even neophytes can #include <stdio.hon day one.

I was granting that he meant prototypes in source code.
But if you take him literally to just mean
making use of prototypes in code, then yes,
I don't think you can write a program for a modern C implementation,
that has any output, without using prototypes.

I hope that you're mistaken about what he said.

I think/hope "ditto" applies to everyone reading clc.

Me too.

(Though I
wouldn't hold my breath waiting for the answer to that.)

I think we would even prefer that Steph Barklay was trolling us
than that this could actually be happening.
But we all know that there's no limit to incompetence anywhere.

--
pete

[pete]

osmium wrote:

Why burden the OP in this thread with a bunch of esoterica on the fine
points of the standard?
Presumably he wants to learn to write programs, not
how to write or interpret standards for a programming language.

OP already knows how to write programs.
OP wants to learn about data structures.

--
pete

[Eric Sosman]

Richard Heathfield wrote:

[...]
You'd think a teacher would know the difference between "principle" and
"principal", wouldn't you?

I blam our flawhed eductaional sistym!

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

[user923005]

On Aug 23, 6:23 pm, Richard Heathfield <[e-mail]:

Steph Barklay said:

I dont think I misunderstood, here are the course guidelines quite
clear about this.

"During this semester, all programs submitted for homework or extra
credit and the project must conform to the following programming
standards:

1. Use of global variables is prohibited

Let's hope he does not ask anyone to print to stout or stderr or read
from stdin.
It's right out, then.

[Old Wolf]

On Aug 24, 1:23 pm, Richard Heathfield <[e-mail]:

8. At the top of the main source file, a narrative must be included
that describes the purpose of the program, who was the principle
programmer on the programming team. If the program went through

You'd think a teacher would know the difference between "principle" and
"principal", wouldn't you?

Maybe the "principle programmer" is the programmer who's
responsible for following design principles?

[Ravishankar S]

No, probably slower -- a lot slower.

The above technique does not speed up compilation (generally compiles
run much slower). On some systems, it will increase the executable
speed of the binary.

No, what I mean is have a seperate source files , but a single header
declaring all that is required. saving preprocrocessing time...

[Army1987]

On Fri, 24 Aug 2007 01:23:37 +0000, Richard Heathfield wrote:

>3. All constants must be in uppercase

This is unusual. It would mean that you couldn't write a program to
print this sentence, since you'd have to use "PROGRAM", say, rather
than "program" (string literals are constants).

#include <stdio.h>
#include <ctype.h>
int main(void)
{
char *s1 = "T WOULD MEAN THAT YOU COULDN'T WRITE A PROGRAM "
"TO PRINT THIS SENTENCE, SINCE YOU'D HAVE TO USE ";
char *s2 = ", SAY, RATHER THAN \"PROGRAM\" (STRING LITERALS "
"ARE CONSTANTS).";
putchar('I');
while (*s1) putchar(tolower(*s1++));
printf("\"PROGRAM\"");
while (*s2) putchar(tolower(*s2++));
puts("");
return 0;
}
--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Richard Tobin]

In article <pa***************************@NOSPAM.it>,
Army1987 <ar******@NOSPAM.itwrote:

>#include <stdio.h>
#include <ctype.h>

I'm not sure that this is allowed, since those header files probably
contain prototypes, and header files were supposed to conform to the
same rules.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Army1987 said:

On Fri, 24 Aug 2007 01:23:37 +0000, Richard Heathfield wrote:

>>3. All constants must be in uppercase

This is unusual. It would mean that you couldn't write a program to
print this sentence, since you'd have to use "PROGRAM", say, rather
than "program" (string literals are constants).

#include <stdio.h>
#include <ctype.h>
int main(void)
{
char *s1 = "T WOULD MEAN THAT YOU COULDN'T WRITE A PROGRAM "
"TO PRINT THIS SENTENCE, SINCE YOU'D HAVE TO USE ";
char *s2 = ", SAY, RATHER THAN \"PROGRAM\" (STRING LITERALS "
"ARE CONSTANTS).";
putchar('I');
while (*s1) putchar(tolower(*s1++));

Very good. But alas! You used a function prototype! :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

Army1987 wrote:

On Fri, 24 Aug 2007 01:23:37 +0000, Richard Heathfield wrote:

>>3. All constants must be in uppercase

This is unusual. It would mean that you couldn't write a program to
print this sentence, since you'd have to use "PROGRAM", say, rather
than "program" (string literals are constants).

#include <stdio.h>
[...]
return 0;
}

Alas, the constant in the `return' statement is not
in upper case. Suggested fix:

typedef { TRUE, FALSE } Boolean;
...
return TRUE;

;-)

(Disclaimer: I didn't invent the `typedef', but ran
across it years ago in somebody else's code. It made for
an interesting debugging session ...)

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

[Peter J. Holzer]

On 2007-08-24 09:12, Ravishankar S <s.***********@de.bosch.comwrote:

>No, probably slower -- a lot slower.
The above technique does not speed up compilation (generally compiles
run much slower). On some systems, it will increase the executable
speed of the binary.

No, what I mean is have a seperate source files , but a single header
declaring all that is required. saving preprocrocessing time...

That depends. It will probably speed up compiling if you compile
everything from scratch. But if you have a build system which
recompiles only those source files which changed or which include a
changed file, you will have to recompile everything a lot more often if
you only have one header file than if you have a lot of little header
files.

(Poor organization may have a similar impact. For example the Minix OS
of course had a lot of include files, but almost all OS parameters were
defined in a single central include file, which was of course included
in almost all system source files. So, if you changed any of these
parameters (which was probably used in a handful of places) you had to
recompile almost everything)

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Charlton Wilbur]

>>>>"o" == osmium <r1********@comcast.netwrites:

oYour instructor is pathetic. He is talking about little toy
oprograms, the kind you write in the very class you are enrolled
oin. My guess is that he has never seen the code for a real
oprogram in his entire life.

Er, based on subsequent statements, and in an attempt to be
charitable, I don't think the instructor was really claiming that
nobody ever uses prototypes. He's teaching a data structures class,
and it sounds like what he really wants is all the code for the
assignments to be in one file, with all the functions preceding the
main() function at the end of the file, and with no mutual recursion.
Allowing multiple files means that he's suddenly got to deal with
multiple files per student and differing build procedures, and he's
probably not interested in teaching a class in Makefiles and tar -cf,
or worse, the IDE du jour; and if this is a data structures class,
it's probably aimed at first- or second-year students, who are in the
process of learning to walk before they run.

On the other hand, had he specified what he wanted, instead of using
silly technical restrictions that he thought he would get what he
wanted, he'd be more likely to get what he wanted, and he'd seem like
less of an idiot. This is a valuable lesson for any programmer or
project manager.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

[Default User]

Richard Heathfield wrote:

Default User said:

void f(void)

That's a "prototype declaration" - i.e. a declaration that is also a
prototype. (That's not all it is, either.)

Of course. However, most situations are NOT comp.lang.c. Even when I
was working on large C projects, prototype declarations were commonly
just clled "prototypes". K&R style wasn't allowed to be used period, so
there was no ambiguity.

When comes down to interpreting an instructor's directions, I think it
highly unlikely that he or she is requiring old-style functions, but
rather is talking about not using separate declaration of functions.

Yes it's a bit of loose terminology, but I really don't think strange
tangential speculation helps this poor guy out.


Brian

[Kenneth Brody]

Richard Heathfield wrote:

>
Steph Barklay said:

[...]

8. At the top of the main source file, a narrative must be included
that describes the purpose of the program, who was the principle
programmer on the programming team. If the program went through

You'd think a teacher would know the difference between "principle" and
"principal", wouldn't you?

[...]

Just on principle, you should report him to the principal.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

Eric Sosman wrote:

>
Army1987 wrote:

On Fri, 24 Aug 2007 01:23:37 +0000, Richard Heathfield wrote:

>3. All constants must be in uppercase
This is unusual. It would mean that you couldn't write a program to
print this sentence, since you'd have to use "PROGRAM", say, rather
than "program" (string literals are constants).

#include <stdio.h>
[...]
return 0;
}

Alas, the constant in the `return' statement is not
in upper case.

It looks like a capital zero to me.

Suggested fix:

typedef { TRUE, FALSE } Boolean;
...
return TRUE;

;-)

(Disclaimer: I didn't invent the `typedef', but ran
across it years ago in somebody else's code. It made for
an interesting debugging session ...)

Sorry, but your capitalization of "Boolean" probably breaks some
other "rule".

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Chris Thomasson]

"Old Wolf" <ol*****@inspire.net.nzwrote in message
news:11**********************@q4g2000prc.googlegro ups.com...

On Aug 23, 11:40 am, Richard Heathfield <[e-mail]:

>Your teacher is 100% wrong, brain-dead, and beyond redemption. Only
fools put code in headers.

Only fools and C++ programmers ;)

Ouch!

[pete]

Charlton Wilbur wrote:

it sounds like what he really wants is all the code for the
assignments to be in one file, with all the functions preceding the
main() function at the end of the file, and with no mutual recursion.

There's nothing wrong with that.

It was OP's second statement which was inflammatory:
"Hi, I'm currently taking a data structures course in C,
and my teacher said that function prototypes are not
allowed in any of our code.
He also said that no professional programmers
use function prototypes."

--
pete

[CBFalconer]

Eric Sosman wrote:

Army1987 wrote:

>Richard Heathfield wrote:

>>>3. All constants must be in uppercase

This is unusual. It would mean that you couldn't write a program
to print this sentence, since you'd have to use "PROGRAM", say,
rather than "program" (string literals are constants).

#include <stdio.h>
[...]
return 0;
}

Alas, the constant in the `return' statement is not
in upper case. Suggested fix:

typedef { TRUE, FALSE } Boolean;
...
return TRUE;

Quibble: All the digits are already upper case, no lower case digit
exists.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Old Wolf wrote:

Richard Heathfield <[e-mail]:

>>8. At the top of the main source file, a narrative must be included
that describes the purpose of the program, who was the principle
programmer on the programming team. If the program went through

You'd think a teacher would know the difference between "principle"
and "principal", wouldn't you?

Maybe the "principle programmer" is the programmer who's
responsible for following design principles?

My principal programming pal takes deep umbrage at this frolicsome
debauchery of the principles of English spelling.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Stephen Sprunk]

"Eric Sosman" <es*****@ieee-dot-org.invalidwrote in message
news:po******************************@comcast.com. ..

Alas, the constant in the `return' statement is not
in upper case. Suggested fix:

typedef { TRUE, FALSE } Boolean;
...
return TRUE;

;-)

(Disclaimer: I didn't invent the `typedef', but ran
across it years ago in somebody else's code. It made for
an interesting debugging session ...)

I can top that:

enum Bool { True, False, FileNotFound };

(from http://worsethanfailure.com/Articles...uth_0x3f_.aspx )

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:
[...]

>>>>3. All constants must be in uppercase

[...]

Quibble: All the digits are already upper case, no lower case digit
exists.

Meta-quibble: Digits are neither upper case nor lower case.
isupper('5') and islower('5') both return 0.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Charlton Wilbur]

>>>>"p" == pete <pf*****@mindspring.comwrites:

pIt was OP's second statement which was inflammatory: "Hi, I'm
pcurrently taking a data structures course in C, and my teacher
psaid that function prototypes are not allowed in any of our
pcode. He also said that no professional programmers use
pfunction prototypes."

Right, but the only evidence we have of that is a student's say so;
and given the choice between a professor really being that
out-of-touch and a student misunderstanding, smart money's on the
student misunderstanding.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

[Joe Wright]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:
[...]

>>>>>3. All constants must be in uppercase

[...]

>Quibble: All the digits are already upper case, no lower case digit
exists.

Meta-quibble: Digits are neither upper case nor lower case.
isupper('5') and islower('5') both return 0.

Watta ya wanna bet? isupper() and islower() treat only isalpha() values.
Just a guess. I haven't looked it up.

As to function prototypes, they are a godsend. They tell the compiler
how to call the function such that the compiler may do some conversions
to make things happen as expected. Consider..

int i = sqrt(2);

...without a prototype for sqrt() in scope, the compiler will call the
sqrt function with a integer (2) and accept its return as an int.

including <math.hwill provide a prototype like..

double sqrt(double);

...which tells the compiler that sqrt takes a double so it will convert 2
to 2.0 while calling the function.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Heathfield]

Joe Wright said:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:
[...]

>>>>>>3. All constants must be in uppercase

[...]

>>Quibble: All the digits are already upper case, no lower case digit
exists.

Meta-quibble: Digits are neither upper case nor lower case.
isupper('5') and islower('5') both return 0.

Watta ya wanna bet?

The farm.

isupper() and islower() treat only isalpha()
values. Just a guess. I haven't looked it up.

I have (although I knew it already - but where a bet is concerned, I
look it up anyway). Both isupper and islower are required to return 0
for digit characters.

You owe me a farm.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999