P
pandit
is this book good for learning C ?
i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
i am a beginning programmer, Kernighan and Ritchie 2e is quite hard on
me.
A
AndersWang
Oops, That's the book I want to introduce to u
U
user923005
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/
A
Anthony Irwin
pandit said:
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
R
Richard Heathfield
Anthony Irwin said:
<cough> No.
<cough> No.
A
Anthony Irwin
Richard said:
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
R
Richard Heathfield
Anthony Irwin said:
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.
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.
E
Ernie Wright
pandit said:
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.h> line 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
D
Default User
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>
I
Ivar Rosquist
Thanks for top-posting. I find it much more convenient than the
officially sanctioned alternative.
officially sanctioned alternative.
D
Default User
Ivar said:
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>
P
pete
Ernie Wright 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.
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.
F
Flash Gordon
Ivar Rosquist wrote, On 22/03/07 20:12:
Thanks for warning us all that you are not worth bothering with.
*PLONK*
<snip>
Thanks for warning us all that you are not worth bothering with.
*PLONK*
C
CBFalconer
Ivar said:
Welcome to the PLONK file. You have just reduced the usefulness of
this newsgroup to you.
E
Ernie Wright
pete said:
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
R
Richard Bos
[ Top-posting corrected. ]
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
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
M
Mark McIntyre
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
J
J. J. Farrell
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.
P
pete
Mark said:
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.lang.c/msg/e510420c9a5cba88
"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.... "
E
Ernie Wright
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?".
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
created a straw man. To restore this bit of context, after "...to a
beginner?", add "On page 5?".
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