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

A

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

August Derleth

Andy said:
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
 
F

Fao, Sean

[...]
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
 
A

Andy

August said:
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).


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.


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

August Derleth

Fao said:
[...]
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
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.

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
 
A

Alan Connor

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".
 
R

Richard Heathfield

Andy said:
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?
 
J

Jirka Klaue

Richard said:
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
 
A

Andy

Richard said:
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?
 
N

Noah Roberts

Alan said:
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 take
>1500 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.
 
J

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
 
A

Andy

Jirka said:
Andy wrote:
...

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

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
 
A

Andy

Jirka said:
Andy wrote:
...

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


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

Sheldon Simms

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
 
A

Andy

Sheldon said:
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
 
M

Mike Wahler

Andy said:
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
 
A

Alan Balmer

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

CBFalconer

Andy said:
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'.
 
R

Richard Heathfield

Jirka said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top