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.
>
Whats bad about ["Practical C Programming", by Steve Oualline]?
It used to be on my "Recommende d" 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
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.
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 >
Re: "a book on c" Kelly & Pohl (4e) - TPA
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 >
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.
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.
>
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>
>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.hindicat e 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.
Comment