just got myself a copy of K&R...

[Andy]

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

I'm loving the exercises they really leave you with a sense of freedom
to do what you want, just follow the rules.

Just a little rant, I would definitely recommend this book
to anyone interested in C. Great addition to anyones library.

cheers....

[August Derleth]

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.
Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO), and
plenty of good examples and clear statements of the rules (that is,
you aren't left trying to figure out which parts of an example
illustrate which rules, and you don't mistake nonstandard things the
author does for good programming).

I'm loving the exercises they really leave you with a sense of freedom
to do what you want, just follow the rules.
And that is what programming is, largely: Following the rules and
creating something within those rules. K&R lays out the rules so well,
you can use it as a reference manual later on, after you've learned
the language from it. I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.

Just a little rant, I would definitely recommend this book
to anyone interested in C. Great addition to anyones library.

I agree. Others will be along shortly with more books to recommend
you. ;)

The ACCU (Association of C & C++ Users) has some good book reviews on
their site, and not just on books about C & C++. Here is their book
review index:

http://www.accu.org/bookreviews/public/index.htm

[Fao, Sean]

"August Derleth" <li***************@yahoo.com> wrote in message
news:b6************************@posting.google.com ...

[...]

I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.

When I first started getting into the world of programming, I thought the
key to learning any language was to learn every single function and operator
and remembering how they are used (I was no more then 10 or 11 years old at
the time). K&R is great because, like any good book, it doesn't just throw
out a bunch of examples without explaining why they work. K&R makes no
attempt to explain all the functions of the standard library because it
starts from the ground up, explaining the rules of the language enough to
let the programmer decide for his or herself what should be used and when.
Writing functions of my own at the time seemed like some so far, out of this
galaxy, topic that I had never even thought I could ever learn how.

The problem with a lot of the beginner level books is that they lead you to
the same frame of mind that had plagued me in the beginning. If there
wasn't a chapter in the book dedicated to my specific task, I didn't know
how to "program" --or was it copy ;-)-- it. It's been a long day so I'm
probably not making sense anymore but what I'm trying to say is that at some
point, if a person really wants to learn how to program, the "For Dummy"
books just won't suffice. And you won't believe how many people refuse to
accept this. I've had friends that have read the Microsoft _By_ _Example_
books and knew nothing after completing the book; yet, swore they did. Ask
them to do anything that isn't in the book and they'll either swear that it
can't be done or attempt to learn how by getting another book of the same
kind. Before you know it, the dumbest person at work has the largest book
colection, reads all of them and doesn't get any smarter.

Have fun,

Sean

[Andy]

August Derleth wrote:

Andy <ma******@bellsouth.net> wrote in message
news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO), and
plenty of good examples and clear statements of the rules (that is,
you aren't left trying to figure out which parts of an example
illustrate which rules, and you don't mistake nonstandard things the
author does for good programming).

I'm loving the exercises they really leave you with a sense of freedom
to do what you want, just follow the rules.

And that is what programming is, largely: Following the rules and
creating something within those rules. K&R lays out the rules so well,
you can use it as a reference manual later on, after you've learned
the language from it. I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.

Just a little rant, I would definitely recommend this book
to anyone interested in C. Great addition to anyones library.

I agree. Others will be along shortly with more books to recommend
you. ;)

The ACCU (Association of C & C++ Users) has some good book reviews on
their site, and not just on books about C & C++. Here is their book
review index:

http://www.accu.org/bookreviews/public/index.htm

thanks for the reply.
glad you agree
great website.

also just a little question.
allot of his examples have the line

while ((c = getchar()) != EOF)
how would input in C equal EOF.

thanks again.

[August Derleth]

"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote in message news:<Qb*****************@news.abs.net>...

"August Derleth" <li***************@yahoo.com> wrote in message
news:b6************************@posting.google.com ...

[...]

I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.
When I first started getting into the world of programming, I thought the
key to learning any language was to learn every single function and operator
and remembering how they are used (I was no more then 10 or 11 years old at
the time).

Yeah, a common mistake. I think it derives from the elementary-level
schools focusing on rote memorization instead of problem-solving.
While rote memorization is useful in programming, it certainly doesn't
aid the learning of the language beyond a certain level.
K&R is great because, like any good book, it doesn't just throw
out a bunch of examples without explaining why they work. K&R makes no
attempt to explain all the functions of the standard library because it
starts from the ground up, explaining the rules of the language enough to
let the programmer decide for his or herself what should be used and when.
Yep. The Standard Library is presented as something most programmers
will always see it as: A `magical' group of subroutines and magic
numbers you can call upon after including certain header files. It is
presented simply as-needed, with the appendix in the back giving a
short description of all of them in turn.

Which I think is the best possible way to present the Standard Library
to a new programmer.
Writing functions of my own at the time seemed like some so far, out of this
galaxy, topic that I had never even thought I could ever learn how.
Heh. Very little in programming is magical. Some of it is esoteric and
badly-documented, some of it is very complex, and some of it is truly
difficult to understand, but little of it is not doable by someone who
will invest the effort in learning it.

And creating subroutines in C is certainly none of the above, except
doable. ;)

The problem with a lot of the beginner level books is that they lead you to
the same frame of mind that had plagued me in the beginning. If there
wasn't a chapter in the book dedicated to my specific task, I didn't know
how to "program" --or was it copy ;-)-- it.
That's right. That's why books on programming must be written by
people who are generally intelligent and /do/ have a deep
understanding of how to put the tricks of the language in context.
Otherwise, it will be trained seals teaching contextless tricks to
other trained seals.
It's been a long day so I'm
probably not making sense anymore but what I'm trying to say is that at some
point, if a person really wants to learn how to program, the "For Dummy"
books just won't suffice.
The "For Dummy" books are just that: For dummies. ;) Anyone who can
gain a deep understanding of a problem will be left behind by the
sheer ineptness of the texts.

But think about this: As complex as good programming is, what does the
sales of the "<Programming Topic> For Dummies" books mean for the
industry as a whole?
And you won't believe how many people refuse to
accept this. I've had friends that have read the Microsoft _By_ _Example_
books and knew nothing after completing the book; yet, swore they did.
Hell, I know people who didn't read that book, don't know jack shit,
and still insist they're intelligent.

It isn't all the book's fault.

<big_grin>
Ask
them to do anything that isn't in the book and they'll either swear that it
can't be done or attempt to learn how by getting another book of the same
kind.
And that, my friend, is why software book publishers always look so
happy.

And why tech support people always want to price high-powered
handguns.
Before you know it, the dumbest person at work has the largest book
colection, reads all of them and doesn't get any smarter.
Nice of the morons to give us clues like that. I'll know who not to
bother in the future.

Have fun,
Sean

Happy hacking,

August

[Alan Connor]

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

--
Alan C this post ends with w
q

[Richard Heathfield]

Andy wrote:

allot of his examples have the line

while ((c = getchar()) != EOF)
how would input in C equal EOF.

It wouldn't, ever. EOF is what happens when there is no more input.

Imagine this. A friend asks you to pull one numbered ball at a time from a
bucket.

He asks, "What have you got?" You reply "19". He makes a note somewhere.
He asks, "What have you got?" You reply "37". He makes a note somewhere.
He asks, "What have you got?" You reply "12". He makes a note somewhere.
He asks, "What have you got?" You reply "22". He makes a note somewhere.
He asks, "What have you got?" You reply "24". He makes a note somewhere.
He asks, "What have you got?" You reply "41". He makes a note somewhere.
He asks, "What have you got?" You reply "7". He makes a note somewhere.

Then he asks, "What have you got?", and you have a look in the bucket, but
there's nothing left.

You reply "We seem to have run out".

He says "How on earth can there be a ball with 'We seem to have run out'
written on it?"

How would you answer him?

Do you now understand EOF?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Jirka Klaue]

Richard Heathfield wrote:

Andy wrote:

allot of his examples have the line

while ((c = getchar()) != EOF)
how would input in C equal EOF.

It wouldn't, ever. EOF is what happens when there is no more input.

This is the intent, but I think it is not guaranteed, nevertheless.

for (;;) {
c = getchar();
if (feof(f) || ferror(f)) break;
...
}

Jirka

[Andy]

Richard Heathfield wrote:

Andy wrote:

allot of his examples have the line

while ((c = getchar()) != EOF)
how would input in C equal EOF.

It wouldn't, ever. EOF is what happens when there is no more input.

Imagine this. A friend asks you to pull one numbered ball at a time from a
bucket.

He asks, "What have you got?" You reply "19". He makes a note somewhere.
He asks, "What have you got?" You reply "37". He makes a note somewhere.
He asks, "What have you got?" You reply "12". He makes a note somewhere.
He asks, "What have you got?" You reply "22". He makes a note somewhere.
He asks, "What have you got?" You reply "24". He makes a note somewhere.
He asks, "What have you got?" You reply "41". He makes a note somewhere.
He asks, "What have you got?" You reply "7". He makes a note somewhere.

Then he asks, "What have you got?", and you have a look in the bucket, but
there's nothing left.

You reply "We seem to have run out".

He says "How on earth can there be a ball with 'We seem to have run out'
written on it?"

How would you answer him?

Do you now understand EOF?

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF. I've had to modify the example programs with something like

if ((c = getchar()) == -1)
break;

or something like that, to actually stop
the execution of the program.

is there a better way around this?

[Noah Roberts]

Alan Connor wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.
Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

I wouldn't say that. Unless I missed it, neither did the authors. K&R
is very basic and straight forward. It sais in <300 what others take1500 pages to say, and it does it well. I remember as a beginner that

was the only book that really made much sense to me.

--
Noah Roberts
- "If you are not outraged, you are not paying attention."

[Jirka Klaue]

Andy wrote:
....

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF. I've had to modify the example programs with something like

if ((c = getchar()) == -1)
break;

or something like that, to actually stop
the execution of the program.

That's bullshit. If EOF is #defined to be -1 (most probably it is),
your code is exactly the same as the code using EOF. If EOF is not
-1, your code will not work at all.

Jirka

[Andy]

Jirka Klaue wrote:

Andy wrote:
...

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF. I've had to modify the example programs with something like

if ((c = getchar()) == -1)
break;

or something like that, to actually stop
the execution of the program.

That's bullshit. If EOF is #defined to be -1 (most probably it is),
your code is exactly the same as the code using EOF. If EOF is not
-1, your code will not work at all.

Jirka

well obviously EOF is not set to -1 because the program never stops,
not even with a blank line, or when you put -1, you can hit enter forever
and the program never stops, the only way to stop it was like that or
testing for ARRAY, to make sure I didn't input a value past the last
index point.

[Jirka Klaue]

Andy wrote:
....

well obviously EOF is not set to -1 because the program never stops,
You don't need to know how EOF is defined, just use the macro EOF.
not even with a blank line, or when you put -1, you can hit enter forever
and the program never stops, the only way to stop it was like that or
testing for ARRAY, to make sure I didn't input a value past the last
index point.

Do you know how to type EOF? Try ^D on unix-like systems and ^Z on DOS/Windows.

Jirka

[Sheldon Simms]

On Fri, 07 Nov 2003 11:37:27 -0500, Andy wrote:

Jirka Klaue wrote:

Andy wrote:
...

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF. I've had to modify the example programs with something like

if ((c = getchar()) == -1)
break;

or something like that, to actually stop
the execution of the program.

That's bullshit. If EOF is #defined to be -1 (most probably it is),
your code is exactly the same as the code using EOF. If EOF is not
-1, your code will not work at all.

Jirka

well obviously EOF is not set to -1 because the program never stops,
not even with a blank line, or when you put -1, you can hit enter forever
and the program never stops, the only way to stop it was like that or
testing for ARRAY, to make sure I didn't input a value past the last
index point.

Andy, the piece of information that you may be missing is that there
usually is a way to "type EOF". On my Linux system, that way is to type
Control-D.

Also you should indeed use EOF in your code instead of -1. There is no
guarantee that -1 will be the number used to indicate EOF (although it
often is).

-Sheldon

[Andy]

Jirka Klaue wrote:

Andy wrote:
...

well obviously EOF is not set to -1 because the program never stops,

You don't need to know how EOF is defined, just use the macro EOF.

not even with a blank line, or when you put -1, you can hit enter forever
and the program never stops, the only way to stop it was like that or
testing for ARRAY, to make sure I didn't input a value past the last
index point.

Do you know how to type EOF? Try ^D on unix-like systems and ^Z on DOS/Windows.

Jirka

there you thanks, thats pretty much what I was
looking for. thanks dude.

[Andy]

Sheldon Simms wrote:

On Fri, 07 Nov 2003 11:37:27 -0500, Andy wrote:

Jirka Klaue wrote:

Andy wrote:
...
Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF. I've had to modify the example programs with something like

if ((c = getchar()) == -1)
break;

or something like that, to actually stop
the execution of the program.

That's bullshit. If EOF is #defined to be -1 (most probably it is),
your code is exactly the same as the code using EOF. If EOF is not
-1, your code will not work at all.

Jirka

well obviously EOF is not set to -1 because the program never stops,
not even with a blank line, or when you put -1, you can hit enter forever
and the program never stops, the only way to stop it was like that or
testing for ARRAY, to make sure I didn't input a value past the last
index point.

Andy, the piece of information that you may be missing is that there
usually is a way to "type EOF". On my Linux system, that way is to type
Control-D.

Also you should indeed use EOF in your code instead of -1. There is no
guarantee that -1 will be the number used to indicate EOF (although it
often is).

-Sheldon

thanks man
that was my problem, couldn't find the EOF input.
cheers

[Mike Wahler]

"Andy" <ma******@bellsouth.net> wrote in message
news:Xl******************@bignews4.bellsouth.net.. .

Richard Heathfield wrote:

Andy wrote:

allot of his examples have the line

while ((c = getchar()) != EOF)
how would input in C equal EOF.
It wouldn't, ever. EOF is what happens when there is no more input.

Imagine this. A friend asks you to pull one numbered ball at a time from a bucket.

He asks, "What have you got?" You reply "19". He makes a note somewhere.
He asks, "What have you got?" You reply "37". He makes a note somewhere.
He asks, "What have you got?" You reply "12". He makes a note somewhere.
He asks, "What have you got?" You reply "22". He makes a note somewhere.
He asks, "What have you got?" You reply "24". He makes a note somewhere.
He asks, "What have you got?" You reply "41". He makes a note somewhere.
He asks, "What have you got?" You reply "7". He makes a note somewhere.

Then he asks, "What have you got?", and you have a look in the bucket, but there's nothing left.

You reply "We seem to have run out".

He says "How on earth can there be a ball with 'We seem to have run out'
written on it?"

How would you answer him?

Do you now understand EOF?

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF.

If the input is coming from a file, the OS will generate
the indication of 'EOF', for keyboard input, most OS's
have assigned a particular keystroke(s) to mean 'EOF',
e.g. 'ctrl-Z' for DOS and Windows. This keystroke will
of course vary among operating systems, if it's available
at all. Check your OS documentation.

I've had to modify the example programs with something like

if ((c = getchar()) == -1)
break;

or something like that, to actually stop
the execution of the program.

is there a better way around this?

See above.

-Mike

[Alan Balmer]

On Fri, 07 Nov 2003 04:18:12 GMT, Alan Connor <zz****@xxx.yyy> wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

That would be a surprise to the people I know who learned C as their
first programming language, from K&R.

--
Al Balmer
Balmer Consulting
re************************@att.net

[CBFalconer]

Andy wrote:

Richard Heathfield wrote:

Andy wrote:

allot of his examples have the line

while ((c = getchar()) != EOF)
how would input in C equal EOF.

It wouldn't, ever. EOF is what happens when there is no more input.

Imagine this. A friend asks you to pull one numbered ball at a time
from a bucket.

He asks, "What have you got?" You reply "19". He makes a note somewhere.
He asks, "What have you got?" You reply "37". He makes a note somewhere.
He asks, "What have you got?" You reply "12". He makes a note somewhere.
He asks, "What have you got?" You reply "22". He makes a note somewhere.
He asks, "What have you got?" You reply "24". He makes a note somewhere.
He asks, "What have you got?" You reply "41". He makes a note somewhere.
He asks, "What have you got?" You reply "7". He makes a note somewhere.

Then he asks, "What have you got?", and you have a look in the bucket,
but there's nothing left.

You reply "We seem to have run out".

He says "How on earth can there be a ball with 'We seem to have run out'
written on it?"

How would you answer him?

Do you now understand EOF?

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF. I've had to modify the example programs with something like

if ((c = getchar()) == -1)
break;

or something like that, to actually stop
the execution of the program.

is there a better way around this?

Yes. The above is undefined, and will only work if EOF is
actually defined to be -1. You should find out how your system
generates EOF from the keyboard, or redirect stdin to come from a
file. The usual EOF signals are CTL-D (Unix) and CTL-Z
(MsDos/Windoze). They may have to be the first characters after a
'\n'.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

Jirka Klaue wrote:

Richard Heathfield wrote:

Andy wrote:

allot of his examples have the line

while ((c = getchar()) != EOF)
how would input in C equal EOF.

It wouldn't, ever. EOF is what happens when there is no more input.

This is the intent, but I think it is not guaranteed, nevertheless.

for (;;) {
c = getchar();
if (feof(f) || ferror(f)) break;

The Standard (or rather, the ANSI C draft, because it's the most convenient
doc to hand right now) says:

"The getc function returns the next character from the input stream pointed
to by stream . If the stream is at end-of-file, the end-of-file indicator
for the stream is set and getc returns EOF . If a read error occurs, the
error indicator for the stream is set and getc returns EOF.

4.9.7.6 The getchar function

[...] The getchar function is equivalent to getc with the argument stdin."
So if your point was that EOF can be returned for a reason other than
I'm-all-out-of-data, then you're correct - it can also be returned on
error. Otherwise, I am not sure what your point is.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Kevin Bracey]

In message <Xl******************@bignews4.bellsouth.net>
Andy <ma******@bellsouth.net> wrote:

Right, so pretty much all of the example programs will run for as long
as you can input, cause there is nothing you can put in to make it
EOF.

There usually _is_ something you can enter as a user to signal EOF. On many
systems, Ctrl+D will do it. Check your implementation's documentation. Also,
if you redirect stdin from a file (usually by using "< filename", you will
get EOF when it reaches the end of the file.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: [phone]
182-190 Newmarket Road Fax: [phone]
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Fao, Sean]

August Derleth wrote:

"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote in message news:<Qb*****************@news.abs.net>...

"August Derleth" <li***************@yahoo.com> wrote in message
news:b6************************@posting.google.c om...

[...]

I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.

When I first started getting into the world of programming, I thought the
key to learning any language was to learn every single function and operator
and remembering how they are used (I was no more then 10 or 11 years old at
the time).

Yeah, a common mistake. I think it derives from the elementary-level
schools focusing on rote memorization instead of problem-solving.
While rote memorization is useful in programming, it certainly doesn't
aid the learning of the language beyond a certain level.

[...]

I never thought about it before but you're probably right. Looking back
at those days, I *was* taught to memorize --_everything_. It probably
also explains why I was such a bad speller up until the point that I
finally stopped trying to remember how to spell everything and learned
how to "sound it out" for myself. I'm still not great but I can
honestly say that I've improved quite a bit. It's funny how I was never
like that with math. I seemed to do quite well teaching myself. But
maybe that's just it. I had an interest in the subject and realized at
an early age how to think through a problem rather then trying to
remember a bunch of seemingly meaningless formulas.

Interesting...Thanks for the brain storm :-).

Sean

[Fao, Sean]

August Derleth wrote:

"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> wrote in message news:<Qb*****************@news.abs.net>...

"August Derleth" <li***************@yahoo.com> wrote in message
news:b6************************@posting.google.c om...

[...]

I've found it a book that ages well, as opposed
to some more beginner-level texts that are largely worthless once
you've moved on.

When I first started getting into the world of programming, I thought the
key to learning any language was to learn every single function and operatorand remembering how they are used (I was no more then 10 or 11 years old atthe time).

Yeah, a common mistake. I think it derives from the elementary-level
schools focusing on rote memorization instead of problem-solving.
While rote memorization is useful in programming, it certainly doesn't
aid the learning of the language beyond a certain level.

[...]

I never thought about it before but you're probably right. Looking back at
those days, I *was* taught to memorize --_everything_. It probably also
explains why I was such a bad speller up until the point that I finally
stopped trying to remember how to spell everything and learned how to "sound
it out" for myself. I'm still not great but I can honestly say that I've
improved quite a bit. It's funny how I was never like that with math. I
seemed to do quite well teaching myself. But maybe that's just it. I had
an interest in the subject and realized at an early age how to think through
a problem rather then trying to remember a bunch of seemingly meaningless
formulas.

Interesting...Thanks for the brain storm :-).

Sean

[Fao, Sean]

Alan Balmer wrote:

On Fri, 07 Nov 2003 04:18:12 GMT, Alan Connor <zz****@xxx.yyy> wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

That would be a surprise to the people I know who learned C as their
first programming language, from K&R.

He didn't say you couldn't use it to learn programming if you had no
prior experience, but the book does assume that you have prior
experience. Bottom line, it doesn't bore the reader with stuff like,
"there are these things called variables which are named memory
locations and we use them for ..." and "to count in binary, we do ...".

[Arthur J. O'Dwyer]

On Fri, 7 Nov 2003, CBFalconer wrote:

Andy wrote:

if ((c = getchar()) == -1)
break;

The above is undefined, and will only work if EOF is ^^^^^^^^^ actually defined to be -1.

Nitpick: I see no undefined behavior here. At most, it's
unspecified behavior. Either:

Case 1. sizeof(int)==sizeof(char).
I have no idea. You're pretty much screwed anyway,
though, since most of the text I/O stuff won't work
in any kind of user-friendly manner.

Case 2. sizeof(int)>sizeof(char) && EOF == -1.
The code works as expected, breaking the loop when
the end of input is encountered.

Case 3. sizeof(int)>sizeof(char) && EOF != -1.
The code does not work as expected; the condition
never becomes true and the loop never terminates.

One of Cases {1,2,3} *must* be the case, unless I'm
missing something fairly basic here. And that makes
it "unspecified," albeit depending on various
implementation-defined characteristics.
Everything else good, though. :)

-Arthur

[Alan Connor]

On Fri, 07 Nov 2003 10:28:59 -0700, Alan Balmer <al******@att.net> wrote:

On Fri, 07 Nov 2003 04:18:12 GMT, Alan Connor <zz****@xxx.yyy> wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...
and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

That would be a surprise to the people I know who learned C as their
first programming language, from K&R.

But not to the thousands who have been completely discouraged by the
book and by the many arrogant elitists found in the field.

--
Alan C this post ends with w
q

[Richard Heathfield]

Alan Connor wrote:

On Fri, 07 Nov 2003 10:28:59 -0700, Alan Balmer <al******@att.net> wrote:

On Fri, 07 Nov 2003 04:18:12 GMT, Alan Connor <zz****@xxx.yyy> wrote:
<snip>

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

That would be a surprise to the people I know who learned C as their
first programming language, from K&R.

But not to the thousands who have been completely discouraged by the
book and by the many arrogant elitists found in the field.

Please provide evidence for your assertion that "thousands have been
completely discouraged by the book". Thank you.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Lew Pitcher]

Alan Connor wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

"This book is meant to help the reader learn how to program in C.
,,,
The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions."

Preface, "The C Programming Language", by Brian W. Kernighan & Dennis M.
Ritchie, Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated
published by Prentice-Hall

It looks like the authors of K&R do not agree with you, Alan.
--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

[Alan Connor]

On Fri, 07 Nov 2003 23:59:42 -0500, Lew Pitcher <lp******@sympatico.ca> wrote:

Alan Connor wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:

Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...

and so far I'm loving it, I like the the authors don't beat
around the bush and just come straight out and say what the book
is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)

K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

"This book is meant to help the reader learn how to program in C.
,,,
The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions."

Preface, "The C Programming Language", by Brian W. Kernighan & Dennis M.
Ritchie, Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated
published by Prentice-Hall

It looks like the authors of K&R do not agree with you, Alan.

"The book is not an introductory programming manual..." K&R

"K&R assumes that you already know how to program....." Me

May I suggest a good ESL course? Logic 101? Hormones?
--
Alan C this post ends with w
q

[Jirka Klaue]

Richard Heathfield wrote:

Jirka Klaue wrote:

Richard Heathfield wrote: ....

It wouldn't, ever. EOF is what happens when there is no more input.
This is the intent, but I think it is not guaranteed, nevertheless.

for (;;) {
c = getchar();
if (feof(f) || ferror(f)) break;

.... So if your point was that EOF can be returned for a reason other than
I'm-all-out-of-data, then you're correct - it can also be returned on
error. Otherwise, I am not sure what your point is.

If all integer types are 32bit wide and CHAR_MAX == INT_MAX, EOF could
be normal data too. That's why my point was, as you noted, that EOF
could be returned for some other reason than end-of-file. Only that I
did have one more reason in mind. :-)
The only reliable method to check for end-of-file seems to be feof(),
doesn't it?

Jirka

[Mark McIntyre]

On Sat, 08 Nov 2003 14:11:21 +0100, in comp.lang.c , Jirka Klaue
<jk****@ee.tu-berlin.de> wrote:

If all integer types are 32bit wide and CHAR_MAX == INT_MAX, EOF could
be normal data too.
EOF is guaranteed to be negative, and of type int, and to mean "no
more data". I believe an implementation such as you mention would be
non-conformant as it would have (as you say) no possible value to use
for EOF.
The only reliable method to check for end-of-file seems to be feof(),
doesn't it?

Depends on your definition of reliable - feof() only returns true
after the end has already been reached. This may be too late to
determine it in many circumstances.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Jirka Klaue]

Mark McIntyre wrote:

Jirka Klaue wrote:

If all integer types are 32bit wide and CHAR_MAX == INT_MAX, EOF could
be normal data too.

EOF is guaranteed to be negative, and of type int, and to mean "no
more data". I believe an implementation such as you mention would be
non-conformant as it would have (as you say) no possible value to use
for EOF.

It would have a possible value. That this value could be used for data
does not matter. Where does the standard say otherwise?

The only reliable method to check for end-of-file seems to be feof(),
doesn't it?

Depends on your definition of reliable - feof() only returns true
after the end has already been reached. This may be too late to
determine it in many circumstances.

Can you provide an example using EOF, which can not be rewritten
using feof()? I'm curious.

Jirka

[Joe Wright]

Mark McIntyre wrote:

On Sat, 08 Nov 2003 14:11:21 +0100, in comp.lang.c , Jirka Klaue
<jk****@ee.tu-berlin.de> wrote:

If all integer types are 32bit wide and CHAR_MAX == INT_MAX, EOF could
be normal data too.

EOF is guaranteed to be negative, and of type int, and to mean "no
more data". I believe an implementation such as you mention would be
non-conformant as it would have (as you say) no possible value to use
for EOF.

The only reliable method to check for end-of-file seems to be feof(),
doesn't it?

Depends on your definition of reliable - feof() only returns true
after the end has already been reached. This may be too late to
determine it in many circumstances.

If 'while ((c = getchar()) != EOF) {}' doesn't work for you, why not..

'while ((c = getchar()), ! feof(stdin)) {}'

--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Mark McIntyre]

On Sun, 09 Nov 2003 14:12:01 +0100, in comp.lang.c , Jirka Klaue
<jk****@ee.tu-berlin.de> wrote:

Mark McIntyre wrote:

Jirka Klaue wrote:

If all integer types are 32bit wide and CHAR_MAX == INT_MAX, EOF could
be normal data too.

EOF is guaranteed to be negative, and of type int, and to mean "no
more data". I believe an implementation such as you mention would be
non-conformant as it would have (as you say) no possible value to use
for EOF.

It would have a possible value. That this value could be used for data
does not matter. Where does the standard say otherwise?

It says that EOF must mean "no more data", which I believe precludes
it from sharing a value with actual data.
If the value of EOF were shared with a real value, there would be no
way for the implementation to reliably signal an error or end-of-data
condition. Some functions are required to do that, so the
implementation could not conform to the requirements of the standard.

The only reliable method to check for end-of-file seems to be feof(),
doesn't it?

Depends on your definition of reliable - feof() only returns true
after the end has already been reached. This may be too late to
determine it in many circumstances.

Can you provide an example using EOF, which can not be rewritten
using feof()? I'm curious.

EOF is used to indicate errors from the character i/o functions. I'm
not sure you can detect errors in fputc otherwise, and I'm pretty sure
feof won't help.

int c = fgetc(stdin);
if(c==EOF)
printf("there was an error reading from stdin, \
but its unlikely to have been an \
end-of-file condition I think...\n");
int cc = fputc(c, stdout);
if(cc==EOF)
printf("there was an error writing to stdout, \
but its not an end-of-file condition\n");
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Chris Torek]

In article <3F***********@earthlink.net>
Joe Wright <jo********@earthlink.net> writes:

If 'while ((c = getchar()) != EOF) {}' doesn't work for you, why not..

'while ((c = getchar()), ! feof(stdin)) {}'

It is an infinite loop when getchar() returns EOF due to input
error (in which case, c==EOF, feof(stdin)==0, and ferror(stdin)!=0).

You can fix this with:

while ((c = getchar()), !feof(stdin) && !ferror(stdin))
...

but I prefer the "c != EOF" test. Systems that have stdio return
valid input data that compares equal to EOF appear to have too many
tough problems implementing the C library, so I choose (consciously,
not accidentally) to avoid them instead of accomodating them.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Lew Pitcher]

Alan Connor wrote:

On Fri, 07 Nov 2003 23:59:42 -0500, Lew Pitcher <lp******@sympatico.ca> wrote:

Alan Connor wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:
Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...
>and so far I'm loving it, I like the the authors don't beat
>around the bush and just come straight out and say what the book
>is sopposed to be. They assume the you have computer experience.

Precisely. K&R is an example of what a technical book should be: No
digressions, no pandering to those who are not the target audience
(programmers should know how to use a computer already, IMNSHO)
K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".
"This book is meant to help the reader learn how to program in C.
,,,
The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions."

Preface, "The C Programming Language", by Brian W. Kernighan & Dennis M.
Ritchie, Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated
published by Prentice-Hall

It looks like the authors of K&R do not agree with you, Alan.

"The book is not an introductory programming manual..." K&R

"K&R assumes that you already know how to program....." Me

"K&R assumes that you already know how to program in another language"
(Alan Connor)

"The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions." (Kernighan & Ritchie)

"It looks like the authors of K&R do not agree with you, Alan" (Me)

I fail to see where in K&R either author explicitly states that they "assume
that you already know how to /program in another language/.". I /do/ see
where they say that they assume some familiarity with programming
/concepts/, but nothing about /knowledge of programming in other languages/.

I reiterate: It looks like the authors of K&R do not agree with you, Alan.
I will give you this: I can't find any evidence to indicate that K&R
/disagree/ with you. They simply do not state anything on the topic.
May I suggest a good ESL course? Logic 101? Hormones?

May I suggest better glasses? Perhaps a course in Technical Writing? Or even
just a parachute for your "jumping to conclusions"?

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

[Alan Connor]

On Sun, 09 Nov 2003 17:12:22 -0500, Lew Pitcher <lp******@sympatico.ca> wrote:

Alan Connor wrote:

On Fri, 07 Nov 2003 23:59:42 -0500, Lew Pitcher <lp******@sympatico.ca> wrote:

Alan Connor wrote:

On 6 Nov 2003 12:07:36 -0800, August Derleth <li***************@yahoo.com> wrote:
>Andy <ma******@bellsouth.net> wrote in message news:<jJ******************@bignews5.bellsouth.net> ...
>
>
>>and so far I'm loving it, I like the the authors don't beat
>>around the bush and just come straight out and say what the book
>>is sopposed to be. They assume the you have computer experience.
>
>Precisely. K&R is an example of what a technical book should be: No
>digressions, no pandering to those who are not the target audience
>(programmers should know how to use a computer already, IMNSHO)
K&R assumes that you already know how to program in another language,
which is quite a different thing from "knowing how to use a computer".

"This book is meant to help the reader learn how to program in C.
,,,
The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions."

Preface, "The C Programming Language", by Brian W. Kernighan & Dennis M.
Ritchie, Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated
published by Prentice-Hall

It looks like the authors of K&R do not agree with you, Alan.

"The book is not an introductory programming manual..." K&R

"K&R assumes that you already know how to program....." Me

"K&R assumes that you already know how to program in another language"
(Alan Connor)

"The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions." (Kernighan & Ritchie)

"It looks like the authors of K&R do not agree with you, Alan" (Me)

I fail to see where in K&R either author explicitly states that they "assume
that you already know how to /program in another language/.". I /do/ see
where they say that they assume some familiarity with programming
/concepts/, but nothing about /knowledge of programming in other languages/.

I reiterate: It looks like the authors of K&R do not agree with you, Alan.
I will give you this: I can't find any evidence to indicate that K&R
/disagree/ with you. They simply do not state anything on the topic.

May I suggest a good ESL course? Logic 101? Hormones?

May I suggest better glasses? Perhaps a course in Technical Writing? Or even
just a parachute for your "jumping to conclusions"?

Lew, listen really closely: You are wrong. You are reading English as
if it was a computer language. It isn't. It's much more complex than
that.

Read the meaning of the statement from K&R as a WHOLE, not the sum of
its parts and not limiting your definitions of the words to one definition,
because the dictionary certainly doesn't.

Look at the "spirit" of the sentence, as in the "spirit of the law".

The authors clearly mean (no Lew, not every word of meaning in a sentence
is literally there) that the book is for people that already know another
language.

Where else is one going to gain "some familiarity with programming concepts"
except by learning a language?

Maybe playing tennis at the club? In Political Science maybe?

And the AMOUNT of prior knowldge they require is considerable.

("some" is not a precise term, Lew)

I know that because I am very new to computers and when I first picked up
K&R it may as well have been in Swahili.

Only after learning how to program in Bash (which IS a high-level programming
language) could I begin to make sense out of K&R.

But you believe what you want. I couldn't care less and am bored with this.

--
Alan C this post ends with w
q

[Alan Connor]

Well Lew, fortunately the Computer Science Professors of America
don't agree with you on this.

I have looked throught the curriculae of over a dozen Universities, Colleges,
and Community/Junior colleges that use K&R as their primary C programming
text, and every one of them teaches either assembly language or a high-level
language first.

I don't think you can find an exception to this.

--
Alan C this post ends with w
q

[Richard Bos]

Lew Pitcher <lp******@sympatico.ca> wrote:

"K&R assumes that you already know how to program in another language"
(Alan Connor)

"The book is not an introductory programming manual; it assumes some
familiarity with basic programming concepts like variables, assignment
statements, loops, and functions." (Kernighan & Ritchie)

"It looks like the authors of K&R do not agree with you, Alan" (Me)

I fail to see where in K&R either author explicitly states that they "assume
that you already know how to /program in another language/.". I /do/ see
where they say that they assume some familiarity with programming
/concepts/, but nothing about /knowledge of programming in other languages/.

In theory, you are correct. In practice, though, I know nobody who is
familiar with programming concepts to the level needed to use K&R
without problems, but does not know how to program. There just aren't
any courses that teach "assignment statements" and "functions" without
also teaching how to program in one language or another.

Admittedly, "one language or another" may be MIX...

Richard

[John Kordyback]

Alan Balmer wrote:

That would be a surprise to the people I know who learned C as their
first programming language, from K&R.

I agree with you. I happen to be one of those people who love K&R. Like
any book, it's not for everyone, but I can't think of any other like it
except Strunk and White's "The Elements of Style". K&R still sits on my
bookshelf after 15 or so years next to Knuth and I still use it frequently.

Some people are better off starting with the "Absolute Beginner's Guide
to C" by Greg M. Perry. It's a little old as well but covers a lot of
basics in a friendlier fashion.

/qb

[Lew Pitcher]

Alan Connor wrote:

Well Lew, fortunately the Computer Science Professors of America
don't agree with you on this.

I have looked throught the curriculae of over a dozen Universities, Colleges,
and Community/Junior colleges that use K&R as their primary C programming
text, and every one of them teaches either assembly language or a high-level
language first.

I don't think you can find an exception to this.

It looks like you are right.

I cannot find any counter-examples, and while K&R may have somehow intended
that "The C Programming Language" be a standalone tutorial, it cannot be
said that it /is/ a standalone tutorial.
--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

[Dan Pop]

In <d9************@aurora.l6s4x6-4.ca> Lew Pitcher <lp******@sympatico.ca> writes:

Alan Connor wrote:

Well Lew, fortunately the Computer Science Professors of America
don't agree with you on this.

I have looked throught the curriculae of over a dozen Universities, Colleges,
and Community/Junior colleges that use K&R as their primary C programming
text, and every one of them teaches either assembly language or a high-level
language first.

I don't think you can find an exception to this.

It looks like you are right.

I cannot find any counter-examples, and while K&R may have somehow intended
that "The C Programming Language" be a standalone tutorial, it cannot be
said that it /is/ a standalone tutorial.

A number of people reported in this very newsgroup that their first
programming language was C and that they learned it from K&R. Certain
parts were harder to understand, but not impossible.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[James Hu]

Alan Connor <zz****@xxx.yyy> wrote in message news:<_u*****************@newsread1.news.pas.earth link.net>...

I have looked throught the curriculae of over a dozen Universities, Colleges,
and Community/Junior colleges that use K&R as their primary C programming
text, and every one of them teaches either assembly language or a high-level
language first.

Perhaps you would find the following link helpful to using K&R2 as a
tutorial to C as a first programming language:

http://www.eskimo.com/~scs/cclass/krnotes/top.html

-- James