By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,260 Members | 1,304 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,260 IT Pros & Developers. It's quick & easy.

"a book on c" Kelly & Pohl (4e)

P: n/a
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.

Mar 21 '07 #1
Share this Question
Share on Google+
35 Replies


P: n/a
Oops, That's the book I want to introduce to u:)

On Mar 21, 12:45 pm, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.

Mar 21 '07 #2

P: n/a
On Mar 21, 9:45 am, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
I have both books. I don't see "A Book On C" as being any easier than
K&R2. Same for H&S. All good books.

Probably, for a pure beginner (with no computer language experience at
all) K. N. King's book is a better bet.
http://knking.com/books/c/

Mar 22 '07 #3

P: n/a
pandit wrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
Hi,

I don't know what others will think of it but I liked the oreilly
practical c book.

It has lots of programming exercises as you go and I am pretty sure it
is ansi 89 compliant. At some point it does use os specific stuff but
it is when it is talking about #ifdef for conditional compiling
depending on whether your using unix or windows.

I would be interested to see what others think of it.

Kind Regards,
Anthony Irwin
Mar 22 '07 #4

P: n/a
Anthony Irwin said:
I don't know what others will think of it but I liked the oreilly
practical c book.
<snip>
>
I would be interested to see what others think of it.
<coughNo.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 22 '07 #5

P: n/a
Richard Heathfield wrote:
Anthony Irwin said:

>>I don't know what others will think of it but I liked the oreilly
practical c book.

<snip>
>>I would be interested to see what others think of it.


<coughNo.
Whats bad about it?

I am now going through k&r2 as every man and his dog says its the best
but practical c got me going does it teach any bad habits or wrong things?

Kind Regards,
Anthony Irwin
Mar 22 '07 #6

P: n/a
Anthony Irwin said:

<snip>
>
Whats bad about ["Practical C Programming", by Steve Oualline]?
It used to be on my "Recommended" list. Then I read it (I don't have a
copy, but one was lying around at work). Oh deary deary me. But that
was about five years ago. I don't now recall what it was that horrified
me so much, so perhaps someone who actually has a copy will oblige by
tearing it into the customary shreds.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 22 '07 #7

P: n/a
pandit wrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
Yes, I think it's good. It's the book I recommend most often, even over
K&R2.

I learned C in 1990, when the 2nd editions of both Kelley and Pohl and
K&R were released. My memory of that time is that I found K&R2 opaque
and confusing. It seems very clear to me when I read it *now*, but I
trust my memory of what it seemed like before I knew the language.

Kelley and Pohl covers very similar territory, and I think either book
can serve as an excellent reference, but Kelley and Pohl does a better
job of *teaching*.

Compare these two descriptions of the #include <stdio.hline in the
very first program example from each book.

K&R2 (p 6):

The first line of the program,

#include <stdio.h>

tells the compiler to include information about the standard input/
output library; this line appears at the beginning of many C source
files. The standard library is described in Chapter 7 and Appendix
B.

Kelley and Pohl (2nd ed, p 5):

#include <stdio.h>

A preprocessor is built into the C compiler. When the command to
compile a program is given, the code is first preprocessed, and then
compiled. Lines that begin with a # communicate with the preproces-
sor. This #include line causes the preprocessor to include a copy of
the header file stdio.h at this point in the code. This header file
is provided by the C system. The angle brackets around <stdio.h>
indicate that this file is to be found in the "usual place," which is
system dependent. We have included this file because it contains
information about the printf() function.

It takes only until p. 10 in Kelley and Pohl to find a more detailed
explanation of #include and .h files. This discussion doesn't occur in
K&R2 until p. 88.

K&R2 is intentionally vague about topics that the authors wish to defer
to later discussion. This makes many aspects of the language seem
deeply mysterious in the early stages of learning it. When the later
discussion is finally encountered--if you last that long--it is often
encumbered by technicalities that further confuse the beginner.

- Ernie http://home.comcast.net/~erniew
Mar 22 '07 #8

P: n/a
An********@gmail.com wrote:
Oops, That's the book I want to introduce to u:)
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>
Mar 22 '07 #9

P: n/a
Thanks for top-posting. I find it much more convenient than the
officially sanctioned alternative.

On Wed, 21 Mar 2007 10:24:13 -0700, AndersWang wrote:
Oops, That's the book I want to introduce to u:)

On Mar 21, 12:45 pm, "pandit" <jala...@gmail.comwrote:
>is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
Mar 22 '07 #10

P: n/a
Ivar Rosquist wrote:
Thanks for top-posting. I find it much more convenient than the
officially sanctioned alternative.
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>
Mar 22 '07 #11

P: n/a
Ernie Wright wrote:
Kelley and Pohl (2nd ed, p 5):

#include <stdio.h>

A preprocessor is built into the C compiler. When the command to
compile a program is given, the code is first preprocessed,
and then compiled.
Lines that begin with a # communicate with the preprocessor.
This #include line causes the preprocessor to include a copy of
the header file stdio.h at this point in the code.
This header file is provided by the C system.
The angle brackets around <stdio.h>
indicate that this file is to be found in the "usual place,"
which is system dependent.
We have included this file because it contains
information about the printf() function.
That's wrong.

Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.

--
pete
Mar 22 '07 #12

P: n/a
Ivar Rosquist wrote, On 22/03/07 20:12:
Thanks for top-posting. I find it much more convenient than the
officially sanctioned alternative.

On Wed, 21 Mar 2007 10:24:13 -0700, AndersWang wrote:
<snip>

Thanks for warning us all that you are not worth bothering with.

*PLONK*
--
Flash Gordon
Mar 22 '07 #13

P: n/a
Ivar Rosquist wrote:
>
Thanks for top-posting. I find it much more convenient than the
officially sanctioned alternative.

On Wed, 21 Mar 2007 10:24:13 -0700, AndersWang wrote:
>Oops, That's the book I want to introduce to u:)

On Mar 21, 12:45 pm, "pandit" <jala...@gmail.comwrote:
>>is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite
hard on me.
Welcome to the PLONK file. You have just reduced the usefulness of
this newsgroup to you.

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

Mar 23 '07 #14

P: n/a
pete wrote:
Ernie Wright wrote:
>Kelley and Pohl (2nd ed, p 5):

#include <stdio.h>

A preprocessor is built into the C compiler. When the command to
compile a program is given, the code is first preprocessed, and
then compiled. Lines that begin with a # communicate with the
preprocessor. This #include line causes the preprocessor to
include a copy of the header file stdio.h at this point in the
code. This header file is provided by the C system. The angle
brackets around <stdio.hindicate that this file is to be found
in the "usual place," which is system dependent. We have included
this file because it contains information about the printf()
function.

That's wrong.

Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.
Is that really the kind of information you want to emphasize to a
beginner? On page 5?

K&R2 p. 33:

The usual practice is to collect extern declarations of variables and
functions in a separate *file*, historically called a /header/, that
is included by #include at the front of each source file. The suffix
.h is conventional for header names. The functions of the standard
library, for example, are declared in headers like <stdio.h>.

They don't get around to explaining that headers don't have to be actual
files until 56 pages later, and they do so only parenthetically. The
C99 standard (7.1.2) does so only in a footnote.

- Ernie http://home.comcast.net/~erniew
Mar 23 '07 #15

P: n/a
Ivar Rosquist <IR*******@irq.orgwrote:

[ Top-posting corrected. ]
On Wed, 21 Mar 2007 10:24:13 -0700, AndersWang wrote:
Oops, That's the book I want to introduce to u:)

On Mar 21, 12:45 pm, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
Thanks for top-posting. I find it much more convenient than the
officially sanctioned alternative.
Thanks for establishing from the start that you're nothing but a troll.
I presume you'll find life in the bozo bin quite convenient as well.

Richard
Mar 23 '07 #16

P: n/a
On Thu, 22 Mar 2007 21:33:14 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:
>pete wrote:
>>
Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.

Is that really the kind of information you want to emphasize to a
beginner?
Well, I dunno. There's two pieces of information above:.

1) It is called a "header".
2) It need not be a plain file.

The first is important because its the correct terminology.
The second is relevant because even popular compilers like MSVC can
store headers in unexpected places, such as binary precompilation
libraries.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 23 '07 #17

P: n/a
On Mar 22, 6:33 pm, Ernie Wright <ern...@comcast.netwrote:
pete wrote:
Ernie Wright wrote:
Kelley and Pohl (2nd ed, p 5):
#include <stdio.h>
A preprocessor is built into the C compiler. When the command to
compile a program is given, the code is first preprocessed, and
then compiled. Lines that begin with a # communicate with the
preprocessor. This #include line causes the preprocessor to
include a copy of the header file stdio.h at this point in the
code. This header file is provided by the C system. The angle
brackets around <stdio.hindicate that this file is to be found
in the "usual place," which is system dependent. We have included
this file because it contains information about the printf()
function.
That's wrong.
Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.

Is that really the kind of information you want to emphasize to a
beginner? On page 5?
Not in that detail, of course. But why would you want to complicatedly
mislead the reader then correct it later, when you could just explain
it more simply and correctly from the outset?

#include <stdio.h>

tells the compiler that you are intending to use the Standard I/O
library facilities, and it makes the compiler aware of all the
information it needs to do so. Why complicate it by talking about
files being read, especially when that's not necessarily true?

Later on we could go on to explain that #include can also be used to
read in user-defined files. That might be a good place to explain that
the standard headers are sometimes implemented in a similar way, but
could be implemented in any way the compiler implementor chooses.

Mar 23 '07 #18

P: n/a
Mark McIntyre wrote:
>
On Thu, 22 Mar 2007 21:33:14 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:
pete wrote:
>
Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.
Is that really the kind of information you want to emphasize to a
beginner?

Well, I dunno. There's two pieces of information above:.

1) It is called a "header".
2) It need not be a plain file.

The first is important because its the correct terminology.
The second is relevant because even popular compilers like MSVC can
store headers in unexpected places, such as binary precompilation
libraries.
And then C programmers, like lcw1964, get confused
and are unable to recognize portable code when they see it.

http://groups.google.com/group/comp....10420c9a5cba88

"p.s. I know I have been advised not to worry, and I won't, but the
curiosity is killing me--if their is no float.h header file, where the
heck is all that good information, and why doesn't the compiler rebel
when I include an *.h file that really doesn't seem to exist? There is
some zen wisdom in all of this I am sure.... "

--
pete
Mar 24 '07 #19

P: n/a
pete wrote:
Mark McIntyre wrote:
>On Thu, 22 Mar 2007 21:33:14 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:
>>pete wrote:

Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.

Is that really the kind of information you want to emphasize to a
beginner?
The removal of an important bit of context from what I wrote here has
created a straw man. To restore this bit of context, after "...to a
beginner?", add "On page 5?".
>Well, I dunno. There's two pieces of information above:.

1) It is called a "header".
2) It need not be a plain file.

The first is important because its the correct terminology.
The second is relevant because even popular compilers like MSVC can
store headers in unexpected places, such as binary precompilation
libraries.

And then C programmers, like lcw1964, get confused
and are unable to recognize portable code when they see it.

http://groups.google.com/group/comp....10420c9a5cba88
It's pretty clear that lcw1964 wasn't on page 5 of an introductory book
on C programming when he asked his original question in that thread. In
fact, he appears to have gotten pretty far without knowing that headers
aren't necessarily files. His misconception was easily corrected and
not particularly harmful.

Not everything is equally "important" and "relevant." This is why, as
I've already pointed out, K&R2 waits until page 89 to say that headers
don't have to be files, and it does this in a parenthetical aside. The
standard relegates this information to a footnote.

It's a useful simplification to refer to stdio.h as a file (and as I've
said, K&R2 also implies this at one point.) The fact that the standard
allows it to be a bit of faerie dust in the compiler isn't terribly
important to know when you're still trying to figure out Hello World.

- Ernie http://home.comcast.net/~erniew
Mar 25 '07 #20

P: n/a
J. J. Farrell wrote:
On Mar 22, 6:33 pm, Ernie Wright <ern...@comcast.netwrote:
>pete wrote:
>>That's wrong.

Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.

Is that really the kind of information you want to emphasize to a
beginner? On page 5?

Not in that detail, of course. But why would you want to complicatedly
mislead the reader then correct it later, when you could just explain
it more simply and correctly from the outset?
Because the allegedly simple explanation is that headers are magic,
which is no explanation at all.
#include <stdio.h>

tells the compiler that you are intending to use the Standard I/O
library facilities, and it makes the compiler aware of all the
information it needs to do so.
Why does the compiler need to be told this? Can't it figure this out by
itself? Is stdio.h a library? Why angle brackets and not quote marks?
What does "#include" mean? What is "Standard I/O" and why do I need it?

If you don't give beginners something concrete to hold onto, they can
quickly be carried away on the winds of scrupulous vagueness and opaque
abstraction.

- Ernie http://home.comcast.net/~erniew
Mar 25 '07 #21

P: n/a
On 21 ═┴Ď, 19:45, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
Bradley L.Jones and
Peter Aitken

" C in 21 days "

Mar 25 '07 #22

P: n/a
On Mar 21, 9:45 pm, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
have you checked ACCU ?
one last piece of advice: stay away from "amazon" reviews. i wasted
thousands of rupees by trusting them :-(

ACCU has very good and unbiased reviews, check them for yourself:

http://www.accu.org/index.php/book_r...39ee0028de08f8

Mar 25 '07 #23

P: n/a
Ernie Wright wrote:
>
pete wrote:
Mark McIntyre wrote:
On Thu, 22 Mar 2007 21:33:14 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:

pete wrote:

Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.

Is that really the kind of information you want to emphasize to a
beginner?
Why not?
I think it's best to get it right from the begining.
The removal of an important bit of context from what I wrote here has
created a straw man. To restore this bit of context, after "...to a
beginner?", add "On page 5?".
Well, I dunno. There's two pieces of information above:.

1) It is called a "header".
2) It need not be a plain file.

The first is important because its the correct terminology.
The second is relevant because even popular compilers like MSVC can
store headers in unexpected places, such as binary precompilation
libraries.
And then C programmers, like lcw1964, get confused
and are unable to recognize portable code when they see it.

http://groups.google.com/group/comp....10420c9a5cba88

It's pretty clear that lcw1964 wasn't on page
5 of an introductory book
on C programming when he asked his original question in that thread.
In fact, he appears to have gotten pretty far
without knowing that headers aren't necessarily files.
His misconception was easily corrected and
not particularly harmful.
lcw1964's misconception was easily corrected because lcw1964
posted to this newsgroup, where misconceptions are corrected;
and which is why I wrote what I wrote in this thread.

lcw1964 wouldn't even attempt to compile
the code example in question, until after
lcw1964 argued that it was nonportable and got corrected.

I don't understand what harm you see in stating
the facts correctly from the start.

It's just really not that complicated:
1) It is called a "header".
2) It need not be a plain file.

--
pete
Mar 25 '07 #24

P: n/a
Sh******@gmail.com wrote:
On 21 ═┴Ď, 19:45, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.

Bradley L.Jones and
Peter Aitken

" C in 21 days "
It's actually "Teach Yourself C in 21 Days."

Mar 25 '07 #25

P: n/a
arnuld wrote:
On Mar 21, 9:45 pm, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.

have you checked ACCU ?
one last piece of advice: stay away from "amazon" reviews. i wasted
thousands of rupees by trusting them :-(
Why do you buy from Amazon? Usually, special versions of those books,
printed and meant to be sold within the Indian subcontinent are
available in most bookshops. They're considerably cheaper than their
original printings, as long as you can live with a paperback and
somewhat cheaper paper.

Mar 25 '07 #26

P: n/a
Ernie Wright wrote:
pete wrote:
>>>
.... snip ...
>>>
Is that really the kind of information you want to emphasize
to a beginner?

The removal of an important bit of context from what I wrote here
has created a straw man. To restore this bit of context, after
"...to a beginner?", add "On page 5?".
This illustrates something about which I periodically indulge in
beard muttering. Snippage should be in units of paragraphs.

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

Mar 25 '07 #27

P: n/a
santosh said:
Sh******@gmail.com wrote:
>On 21 ═┴Ď, 19:45, "pandit" <jala...@gmail.comwrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard
on me.

Bradley L.Jones and
Peter Aitken

" C in 21 days "

It's actually "Teach Yourself C in 21 Days."
Followed by several years of discovering why attempting to do it in 21
days was a mistake. Better to get a decent book that doesn't
artificially raise your hopes at the start.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 26 '07 #28

P: n/a
On Mar 25, 12:30 am, Ernie Wright <ern...@comcast.netwrote:
J. J. Farrell wrote:
On Mar 22, 6:33 pm, Ernie Wright <ern...@comcast.netwrote:
pete wrote:
>That's wrong.
>Whether or not stdio.h exists as a file
in a C implementation is system dependent.
stdio.h is properly refered to as a "header"
rather than as a "header file"
when discussing C in general.
Is that really the kind of information you want to emphasize to a
beginner? On page 5?
Not in that detail, of course. But why would you want to complicatedly
mislead the reader then correct it later, when you could just explain
it more simply and correctly from the outset?

Because the allegedly simple explanation is that headers are magic,
which is no explanation at all.
#include <stdio.h>
tells the compiler that you are intending to use the Standard I/O
library facilities, and it makes the compiler aware of all the
information it needs to do so.

Why does the compiler need to be told this?
Because, in a very limited sense, putting this line in switches the
compiler to understand a particular dialect of C - certain terms
become reserved, for example, and various important facilities become
available.
Can't it figure this out by itself?
No. It can't tell whether or not I want it to compile this "dialect"
unless I tell it.
Is stdio.h a library?
No, that's one of a large number of things that it's not. The list
begins with aardvark.
Why angle brackets and not quote marks?
Or excalamtion marks, or upside down question marks? Because that's
how the specifiers of the language specified it.
What does "#include" mean?
In this context, what I said. It can also be used for other things
which will be introduced later.
What is "Standard I/O" and why do I need it?
Easily answered.

Just how would incorrectly telling them that stdio.h is a file help
with any of these questions? They can all be answered at this point if
necessary without any need to go wandering off into incorrect and
irrelevant information about reading in files.
If you don't give beginners something concrete to hold onto, they can
quickly be carried away on the winds of scrupulous vagueness and opaque
abstraction.
Indeed, but how does giving them incorrect information which doesn't
even answer any of their questions help?

Mar 26 '07 #29

P: n/a
On Mar 25, 7:57 pm, "santosh" <santosh....@gmail.comwrote:

Why do you buy from Amazon? Usually, special versions of those books,
printed and meant to be sold within the Indian subcontinent are
available in most bookshops. They're considerably cheaper than their
original printings, as long as you can live with a paperback and
somewhat cheaper paper.
YES, you are right and MOST of these books are not available in India.
take these as examples:

Practical Common Lisp [1], C: A Reference Manual by H&S, C: A Modern
Approach by K.N. King, PAIP [2], Introduction to computing and
algorithms by Shackleford
[3], Data Structures and Algorithms in C++ by Adam Drozdek [4] & many
many other important books.

in 40% of the cases i have alternatives available but for the rest, no
option and when people say India is a high-tech country then i feel :-
( because our basic problems are still here e.g. In well known city,
Chandigarh, no matter which college you join:

1.) nobody had ever heard of K&R, they just use "Let Us C" by Kanitkar
[5].
2.) they teach a language named VC++, if you say "ok, you are learning
C++", then students *quickly* reply: "NO, i am learning VC++ language,
not C++"

sadly, they are also learning "Turbo C" with "conio.h", the Standard
Library

BTW, who is this "K.N.King" and "Harbison" and "Steele". what the heck
is "C unleashed"

it *is* my Hi-Tech country

:-(

-- arnuld
http://arnuld.blogspot.com

[1] http://www.gigamonkeys.com/book/
[2] http://norvig.com/paip.html
[3] http://www.accu.informika.ru/bookrev...algorithms.htm
[4] http://www.accu.informika.ru/bookrev...algorithms.htm
[5] http://www.sapnaonline.com/MoreInfoB...cID=EBK0008879

Mar 26 '07 #30

P: n/a
arnuld wrote:
>
.... snip ..
>
BTW, who is this "K.N.King" and "Harbison" and "Steele". what the
heck is "C unleashed"
"C Unleashed" is a light weight (under two tons) tome authored by
R. Heathfield and associates.

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

Mar 26 '07 #31

P: n/a
J. J. Farrell wrote:
Just how would incorrectly telling [beginners] that stdio.h is a file
help with any of these questions?
Because that's how people learn. We start with the concrete and simple
and progress to the abstract and elaborate. The original simple idea
becomes the archetype of a category. We start with stdio.h as a file,
and progress to #include <stdio.hbeing file-insertion-like in its
effect.

We teach first graders that you can't subtract a bigger number from a
smaller one, then later tell them about negative numbers. We say that
you can't take the square root of a negative number, then tell them that
not only can this be done, it has a physical meaning applied daily in
physics and electrical engineering. We teach Newton before Einstein and
the Bohr atom before the Schr÷dinger atom.

If this weren't the way people learn, then we wouldn't have any need for
books about C. We could all learn directly from the Standard, and our
understanding of C would emerge fully formed. We'd all be instant
experts.

In light of all this, "stdio.h is a file" is *not* incorrect. It is
*incomplete*. It is squarely on the path to the truth in a way that
"stdio.h is a library" and "stdio.h is an aardvark" are not.

- Ernie http://home.comcast.net/~erniew
Mar 26 '07 #32

P: n/a
pete wrote:
I don't understand what harm you see in stating
the facts correctly from the start.
See my reply to J. J. Farrell.

As for harm, I understood your initial post in this thread to be, not
merely an interjection of correctness, but a criticism of Kelley and
Pohl, and I think it may turn beginners away from a good book that they
might find more accessible than K&R2.

- Ernie http://home.comcast.net/~erniew
Mar 26 '07 #33

P: n/a
pandit wrote:
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
I learned to program in C from it, as a physics student I really liked
the style and especially the exercises in it. After nearly 20 years, I
still remember some of those excellent exercises... particularly the
Hamilton path & knights tour problems. So hard, that you knew not all
students would make it. Great!

A Book on C, is not the best choice for a CS student, for for others it
can open their eyes into the fun of C programming. But.. do read K&R2
afterwards!

--
Tor
Mar 28 '07 #34

P: n/a
On Mon, 26 Mar 2007 12:40:08 -0400, Ernie Wright <er****@comcast.net>
wrote:
<snip>
Because that's how people learn. We start with the concrete and simple
and progress to the abstract and elaborate. <snip>
In light of all this, "stdio.h is a file" is *not* incorrect. It is
*incomplete*. It is squarely on the path to the truth in a way that
"stdio.h is a library" and "stdio.h is an aardvark" are not.
However, 'aardvark' is the name of the change management tool used by
The Austin Group, which developed and maintains the recentlyish-merged
POSIX/XPG standard, which effectively incorporates and extends C, and
thus in that somewhat limited context it sometimes makes sense to say
'this is a stdio.h aardvark'. <G><?>

Apr 15 '07 #35

P: n/a
In article <11**********************@e65g2000hsc.googlegroups .com>,
ja*****@gmail.com says...
is this book good for learning C ?

i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.

"Pointers on C" by Kenneth A. Reek is, IMHO, the best introductory book
on C programming that I have seen, a sentiment I was gratified to see
echoed almost word for word by Francis Glassborrow in his ACCU review.

However, Glassborrow believes that "Pointers on C" is best suited for
someone with some prior programming experience. I'm not sure I agree,
but a good choice for a beginning programmer might be the "C Primer
Plus, 5th Edition" by Stephen Prata. In spite of its misleading title,
this book teaches C, not C++, but it also does take the time to explain
where the languages diverge.

Jan Werner

--
FR*********************@NOSPAM.ORG
Apr 25 '07 #36

This discussion thread is closed

Replies have been disabled for this discussion.