Advanced Books
David Mohorn
>>>less) I bought a Schildt's book intended as a basic introduction to
>>>C++. If somebody happens to have that book, I suggest to ignore both
>>>left- and right-hand pages; just with the same words of Steve:
>>>uninspired, poorly organized etc. (I am not very proficient in
>>>English :-). To all book buyers: look at the publisher's name...
>>>prefer firms like Addison-Wesley that have competent referees...
>>>Don't buy Schildt.
Oh, C'mon guy! Aren't you being a bit tough on Schildt? I mean, I
think he writes the best books--they are easy-to-read, give good
explanations, and presents everything in a well-to-do organized manner.
I have the following Schildt books:
Teach Yourself C (EXCELLENT FIRST-TIMER'S BOOK TO LEARNING C!!!)
Teach Yourself C++
Turbo C/C++: The Complete Reference
C the Pocket Reference, 2nd Edition
The Art of C
Born to Code C
Advanced C
I wouldn't sell any of these books. All are priceless to me (Born to
Code C and Art of C are basically the same books with a couple new
chapters.) And whoever said that Schildt may not know advanced topics,
that's purely nonsense. If anyone has ever read his Advance C book, he
definitely knows what he's doing.
I do, however, wish Schildt would come out with a 2nd Edition of his
Teach Yourself C. This book is far better than the umpteenth editions
the Waite Group Press has published from "The Waite Group's C Primer"
series!
C>so are TAB books, and QUE books... and im getting SO tired of these new books
>STILL having void main(void) in them!!!!!!!!!!!!!1 get it right!
I am not sure what book you are referring to, but if you are speaking of
Schildt's, this was necessary in the beginning until the void data type
was explained. This is what makes this book so great. Everything is
covered one step at a time. Nothing is given in a program or example
that isn't explained first! Programs that do:
#include <stdio.h>
int main(int argc, char argv[])
{
printf("Hello World!\n");
return 0;
}
Doesn't mean anything to me. If they would cut out all the nonsense and
just make it:
void main(void)
{
puts("Hello World");
}
And present everything else gradually, it would make it easier for the
newcomer to grasp.
RIME: ->1369 FIDO: (1:275/102) INTERNET: david....@select.wyvern.com
---
þ QMPro 1.52 þ WARNING: Never stand between a fire hydrant and a dog...
David Mohorn
>>C>so are TAB books, and QUE books... and im getting SO tired of these new
>books
>> >STILL having void main(void) in them!!!!!!!!!!!!!1 get it right!
>>
>>I am not sure what book you are referring to, but if you are speaking of
>>Schildt's, this was necessary in the beginning until the void data type
>>was explained. This is what makes this book so great. Everything is
>>covered one step at a time. Nothing is given in a program or example
>>that isn't explained first! Programs that do:
>>
>>#include <stdio.h>
>>
>>int main(int argc, char argv[])
>>{
>> printf("Hello World!\n");
>>
>> return 0;
>>}
>>
>>Doesn't mean anything to me. If they would cut out all the nonsense and
>>just make it:
>>
>>void main(void)
>>{
>> puts("Hello World");
>>}
>>
>>And present everything else gradually, it would make it easier for the
>>newcomer to grasp.
W>Doesn't the fact that it's just plain WRONG bother you?
W>The whole point is that
W>void main(void) {...}
W>is an incorrect definition. The only legal ANSI C definitions (in a
>hosted environment) are
Who cares about ANSI! The point I was trying to say is that the author
doesn't bother the reader with trying to understand all of this at once.
Returning values from functions and whatnot are discusses, but it is
later, when the reader knows and understands the various types that C
uses.
W>int main(void) {...}
>and
>int main(int argc, char **argv) {...}
W>The fact that 'void main(void)' might happen to work with a particular
>compiler is irrelevant, there are lots of things that work on a
>particular compiler but have undefined behavior. Even if your compiler
>specifically blesses that definition as an extension, you aren't
>coding in ANSI C if you use it. You're program is in a language that
>might look close to ANSI C and it could fail mysteriously on an
>another platform when compiled with an ANSI C compiler.
Frankly, I can care less about ANSI. Yes, if I programmed across
multiple processors, I will consider it. But, I think the vast majority
program on the same type of processor. If you are planning to do
anything "serious" on whatever particular processor, you are going to
have to do it via the hardware, so it won't be "ANSI-compatible" then!!!
I program primarily on the IBM/compatible systems. I can care less how
UNIX or any of the other Operating Systems do it. If I want my program
to run on a UNIX processor too, I will write the program so it can be
ported over to it easily!
Let's C great games like DOOM and Wolfenstein written using ANSI
standard. Yeah! It ain't gonna work! ANSI is only good for stupid
text and standard file I/O operations. No graphics, no sound, no
hardware-level specific operations. In otherwords, it is just a
"stupid, generic program"!
W>The presence of errors like this in books (and specifically in a book
>annotating the ANSI C Standard) cast doubts on how well the rest of
>the material can be trusted.
It isn't an error. I only wish you all would pick on the authors who
have source code upon source code listings in books that are blantantly
error-prone! Nothing bothers me more than shelling out $29+ for a book
and begin typing in the examples and find out the author or the editor
goofed! At least Schildt's book seldom, if ever, have any errors!
---
þ QMPro 1.52 þ Programming is 10% inspiration and 90% debugging.
Dan Pop
>covered one step at a time. Nothing is given in a program or example
>that isn't explained first! Programs that do:
>
>#include <stdio.h>
>
>int main(int argc, char argv[])
>{
> printf("Hello World!\n");
>
> return 0;
>}
This shows that you don't even know how to correctly declare the main
function.
If you learned C from Schildt's books, this is quite understandable.
>
>Doesn't mean anything to me. If they would cut out all the nonsense and
>just make it:
>
>void main(void)
>{
> puts("Hello World");
>}
Now, explain me, please, why this variant is superior or more easy to
understand for a beginner than:
main()
{
puts("Hello World");
}
My variant is shorter, and more important, _correct_. It has one big
disadvantage: it teaches you virtually nothing about C :-)
And now, let's have a look at the K&R2 variant of the same program:
#include <stdio.h>
main()
{
printf("hello, world\n");
}
This isn't significantly bigger than yours, only a little bit more
difficult to understand, but it teaches you a lot of things about C:
- You have to start every program with #include <stdio.h>, because the
C i/o subsystem needs it. You just can't write any meaningful program
without it, so there is little reason to postpone its introduction.
- main() is a _correct_ declaration for the main function, if you don't
need access to the command line arguments.
- It introduces the printf function, which will be heavily used in the
next examples. You can't do too much with puts, so this function could
be completely omitted from the tutorial part of the book. No need to
clutter the text (and the reader's mind) with things which are simply
not needed to understand the language and its usage.
- It introduces escapes sequences, which will also be needed by the next
examples. '\n' is essential even for the simplest interactive program.
All these, in a very simple and easy to understand example. The reader
will certainly not be confused or exhausted after reading the few
explanations needed to understand how this program works.
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Peter Seebach
>Oh, C'mon guy! Aren't you being a bit tough on Schildt? I mean, I
>think he writes the best books--they are easy-to-read, give good
>explanations, and presents everything in a well-to-do organized manner.
And he presents it *WRONG*.
Many of the things he says about the language are *FALSE*. This is a
BAD thing.
>And whoever said that Schildt may not know advanced topics,
>that's purely nonsense. If anyone has ever read his Advance C book, he
>definitely knows what he's doing.
He obviously doesn't; anyone who knows what he's doing well enough to
cover advanced topics doesn't consistently* make basic mistakes.
>I am not sure what book you are referring to, but if you are speaking of
>Schildt's, this was necessary in the beginning until the void data type
>was explained. This is what makes this book so great. Everything is
>covered one step at a time. Nothing is given in a program or example
>that isn't explained first! Programs that do:
And here is where you look like a COMPLETE and utter idiot.
The problem with "void main" is that it is WRONG. It is NOT LEGAL.
>#include <stdio.h>
>
>int main(int argc, char argv[])
>{
> printf("Hello World!\n");
>
> return 0;
>}
How about
#include <stdio.h>
main()
{
printf("Hello, World!\n");
exit(0);
}
?
>Doesn't mean anything to me. If they would cut out all the nonsense and
>just make it:
>void main(void)
This is NOT LEGAL. READ* the ANSI standard. main() *MUST* return an
integer.
>{
> puts("Hello World");
>}
This is okay, but prÚntf is just as nice, and more useful in general.
>And present everything else gradually, it would make it easier for the
>newcomer to grasp.
Yes, and the newcomer would come out a blithering idiot who writes broken
code.
It's better to present something difficult than something wrong.
>RIME: ->1369 FIDO: (1:275/102) INTERNET: david....@select.wyvern.com
>---
> þ QMPro 1.52 þ WARNING: Never stand between a fire hydrant and a dog...
-seebs
--
Peter Seebach - se...@solutions.solon.com -- I need a job! Hire me!
GAT(CS/M/P/SS) d-- H++ s+: !g p? !au a- w+++ v+++/* C++++ UB/V++++ P+ L b+++ !D
3+(NetBSD/Amiga) E- N+++ K !W--- M++/-- V- -po+ Y+ t 5++ jx R G'''' tv- B---
e++ u** h--- f+ r+++ !n x+++* --SeebS-- / The Laughing Prophet
Peter Seebach
>David Mohorn (david....@sourcebbs.com) wrote:
[ more garbage about schildt knowing what he was doing, presumably better
than 9899-1990 does ]
>I don't understand why people buy a ton of books on C. I fully agree
>with the statement that "C is not a big language, and it is not well
>served by a big book." (K&R II, p. ix).
>I have the following books on C on my bookshelf.
> The C Programming Language, Second Edition (K&R II)
Uhm. s/books/book. :)
>The only other book that I want to get is K&R I because I sometimes
>have to work with non-ANSI compilers. What do the advanced books give
>you that K&R II doesn't? I think that topics like data-structures and
>other algorithms are better suited by books devoted to algorithms.
>Plus, it's easier to apply this knowledge to other procedural
>languages. The same goes for topics like Unix programming, X, DSP,
>etc.
Yup. I have a Posix Programmer's Guide (Donald Lewine) that I've found
handy for checking POSIX standards, I have the _Annotated ANSI C Standard_
(I read the left pages for information, the right pages for laughs), K&R1,
K&R2, uhm... uhm... I suppose I have a ton of other books, but none of
them are on C.
Definite must: _C Traps and Pitfalls_, Andrew Koenig. Very good book. You
may not keep it on your shelf, but read it at least twice.
Having a good library is important, but I can't see why you'd need books
on C beyond one solid reference.
>Beaker aka Matt Donadio | Life is short, --- __ o __~o __ o
>don...@mxd120.rh.psu.edu | ride like ---- _`\<, _`\<, _`\<,
>--- Penn State Cycling ---| the wind. --- ( )/( ) ( )/( ) ( )/( )
>====================================URL: http://mxd120.rh.psu.edu/~donadio
Morgan Gregory Lake
: I don't understand why people buy a ton of books on C. I fully agree
: with the statement that "C is not a big language, and it is not well
: served by a big book." (K&R II, p. ix).
: I have the following books on C on my bookshelf.
: The C Programming Language, Second Edition (K&R II)
I agree that in most cases K&R is the only book on C that you need;
however I still have a number of other books on C (The C Companion)
for instance, an excelent book not the first one I go to but I still
use it. I have others that were good for what I needed them for,
learning, not complicated, not technical.
: The only other book that I want to get is K&R I because I sometimes
: have to work with non-ANSI compilers. What do the advanced books give
: you that K&R II doesn't? I think that topics like data-structures and
: other algorithms are better suited by books devoted to algorithms.
: Plus, it's easier to apply this knowledge to other procedural
: languages. The same goes for topics like Unix programming, X, DSP,
: etc.
Yes that's true, I have books that are devoted to specific
applications of C, data structures, compression, things that can't be
well served by a genneral book on C. Anyway, that's my two bits
worth, agree, disagree, I don't care.
--
------
ml...@netcom.com | CS Major
Phil Paxton
>error-prone! Nothing bothers me more than shelling out $29+ for a book
>and begin typing in the examples and find out the author or the editor
>goofed! At least Schildt's book seldom, if ever, have any errors!
Most editors aren't allowed to touch the code. It almost always goes
into print as the author supplies it. Many of the editors I know even
have "No proofing" set against the code listings to hide the source from
the spellchecker...
--
---------------------
Phil Paxton
Fishers, Indiana, USA
David Mohorn
S>>And whoever said that Schildt may not know advanced topics,
>>that's purely nonsense. If anyone has ever read his Advance C book, he
>>definitely knows what he's doing.
S>He obviously doesn't; anyone who knows what he's doing well enough to
>cover advanced topics doesn't consistently* make basic mistakes.
Such as? Can you be more specific?
S>>I am not sure what book you are referring to, but if you are speaking of
>>Schildt's, this was necessary in the beginning until the void data type
>>was explained. This is what makes this book so great. Everything is
>>covered one step at a time. Nothing is given in a program or example
>>that isn't explained first! Programs that do:
S>And here is where you look like a COMPLETE and utter idiot.
S>The problem with "void main" is that it is WRONG. It is NOT LEGAL.
S>>#include <stdio.h>
>>
>>int main(int argc, char argv[])
>>{
>> printf("Hello World!\n");
>>
>> return 0;
>>}
S>How about
>#include <stdio.h>
>main()
>{
> printf("Hello, World!\n");
> exit(0);
>}
For a newcomer to C, having to explain what #include does, exit(), etc,
is just too much burdensome detail. By declaring main as returning
void, you can postpone the discussion of functions returning values
until later in the book, like his "Teach Yourself C" book so blantantly
does!
S>>Doesn't mean anything to me. If they would cut out all the nonsense and
>>just make it:
S>>void main(void)
>This is NOT LEGAL. READ* the ANSI standard. main() *MUST* return an
>integer.
I am not saying that this isn't the standard, I am just saying that it
is needless detail for the beginner in learning C. As long as it is
covered later in the chapters, what does it hurt?
---
þ QMPro 1.53 þ ATTN: Drop your carrier... We have you surrounded!
Lawrence Kirby
david....@sourcebbs.com "David Mohorn" writes:
> >>>I did not see this particular book, but a couple of years ago (maybe
> >>>less) I bought a Schildt's book intended as a basic introduction to
> >>>C++. If somebody happens to have that book, I suggest to ignore both
> >>>left- and right-hand pages; just with the same words of Steve:
> >>>uninspired, poorly organized etc. (I am not very proficient in
> >>>English :-). To all book buyers: look at the publisher's name...
> >>>prefer firms like Addison-Wesley that have competent referees...
> >>>Don't buy Schildt.
>
>Oh, C'mon guy! Aren't you being a bit tough on Schildt? I mean, I
>think he writes the best books--they are easy-to-read, give good
>explanations, and presents everything in a well-to-do organized manner.
>
>I have the following Schildt books:
>
>Teach Yourself C (EXCELLENT FIRST-TIMER'S BOOK TO LEARNING C!!!)
>Teach Yourself C++
>Turbo C/C++: The Complete Reference
>C the Pocket Reference, 2nd Edition
>The Art of C
>Born to Code C
>Advanced C
The problem is that if you only learn from Schildt books you'll never
realise the language he is describing is not C - it is Schildt-C. It is
a similar language but has some significant differences. This will hit
you when you use one of the many (majority) of compliers which understand
C and not Schildt-C.
>I wouldn't sell any of these books. All are priceless to me (Born to
>Code C and Art of C are basically the same books with a couple new
>chapters.) And whoever said that Schildt may not know advanced topics,
>that's purely nonsense. If anyone has ever read his Advance C book, he
>definitely knows what he's doing.
Whether he knows about advanced topics or not he does not understand the
C standard documents. His 'Annotated ANSI C Standard' is ample proof of
that.
>I am not sure what book you are referring to, but if you are speaking of
>Schildt's, this was necessary in the beginning until the void data type
>was explained. This is what makes this book so great. Everything is
>covered one step at a time. Nothing is given in a program or example
>that isn't explained first! Programs that do:
>
>#include <stdio.h>
>
>int main(int argc, char argv[])
>{
> printf("Hello World!\n");
>
> return 0;
>}
>
>Doesn't mean anything to me. If they would cut out all the nonsense and
>just make it:
>
>void main(void)
>{
> puts("Hello World");
>}
A case in point - neither of these are valid C programs.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
david....@sourcebbs.com "David Mohorn" writes:
>For a newcomer to C, having to explain what #include does, exit(), etc,
>is just too much burdensome detail.
There is absolutely no need to explain all of this on the first page of
the book. You provide a template which the newcomer uses to produce working
programs. There is no need to explain the precise workings of that template
until later. What is essential is that the newcomer becomes accustomed
to the correct format of a C program right from the start and doesn't have
to relearn what they thought they knew - this just results in pure confusion.
Later on you get somebody skimming through the book, sees void main() without
seeing the text later on explaining that it is illegal, and quite reasonaly
goes on to use it in his own program.
>By declaring main as returning
>void, you can postpone the discussion of functions returning values
>until later in the book, like his "Teach Yourself C" book so blantantly
>does!
Is saying you should use a format such as:
#include <stdio.h>
int main(void)
{
return 0;
}
really so daunting for the beginner? You could even cut the 3rd line
down to main() if you felt like it but I see no advantage in this.
>S>>Doesn't mean anything to me. If they would cut out all the nonsense and
> >>just make it:
>
>S>>void main(void)
> >This is NOT LEGAL. READ* the ANSI standard. main() *MUST* return an
> >integer.
>
>I am not saying that this isn't the standard, I am just saying that it
>is needless detail for the beginner in learning C. As long as it is
>covered later in the chapters, what does it hurt?
Teaching incorrect code is always going to be harmful because somebody
is quite reasonably going to assume it is correct. It is especially crazy
when, like here, it doesn't actually gain you anything.
Tangible harm: the wasted bandwidth in comp.lang.c discussing void main().
I wonder how much of this is directly attributable to Schildt.
Pete Holsberg
: And now, let's have a look at the K&R2 variant of the same program:
: #include <stdio.h>
: main()
: {
: printf("hello, world\n");
: }
: This isn't significantly bigger than yours, only a little bit more
: difficult to understand,
: but it teaches you a lot of things about C:
: - You have to start every program with #include <stdio.h>, because the
: C i/o subsystem needs it. You just can't write any meaningful program
: without it, so there is little reason to postpone its introduction.
: - main() is a _correct_ declaration for the main function, if you don't
: need access to the command line arguments.
Correct in what sense?
: All these, in a very simple and easy to understand example. The reader
Max Cohan
It was one of the 1st C books I bought...I tought it was great
until I actually tried to USE any of it...
it's not bug free, it's not commercial quality, it's not even
technically sound.
Very very bad buy... the book was easy to read and understand
SURE... but GIGO!
Randy Edwards
o experience working on progressive political and social issues;
o organized and self-motivated;
o ab
David Mohorn
M>Born to Code is C is GARBAGE
I disagree. Maybe you are just a poor typist. I have not had any
problems with any of the code. Since you stated that it was one of the
first books you bought, I assume you were new to C programming and
probably didn't know what you were typing; thus, this could be the
reason for your attitude.
Schildt is a very good author and I stand behind opinion.
---
þ QMPro 1.53 þ Story of a Tagline thief: I came, I read, I stole.
K A Goatman
>Who cares about ANSI! The point I was trying to say is that the author
>doesn't bother the reader with trying to understand all of this at once.
>Returning values from functions and whatnot are discusses, but it is
>later, when the reader knows and understands the various types that C
>uses.
>Frankly, I can care less about ANSI. Yes, if I programmed across
>multiple processors, I will consider it. But, I think the vast majority
>program on the same type of processor. If you are planning to do
>anything "serious" on whatever particular processor, you are going to
>have to do it via the hardware, so it won't be "ANSI-compatible" then!!!
>I program primarily on the IBM/compatible systems. I can care less how
>UNIX or any of the other Operating Systems do it. If I want my program
>to run on a UNIX processor too, I will write the program so it can be
>ported over to it easily!
I learnt to program in C on the PC using K & R II. I never dreamed that
three years later my code would be compiled on a Sun workstation ... but
it was and it worked because I followed what I was taught from the start.
>Let's C great games like DOOM and Wolfenstein written using ANSI
>standard. Yeah! It ain't gonna work! ANSI is only good for stupid
>text and standard file I/O operations. No graphics, no sound, no
>hardware-level specific operations. In otherwords, it is just a
>"stupid, generic program"!
The tragedy of this posting is that oneday you may find out the hard way
that the ANSI standard was _not_ compiled for the sheer pleasure of it and
that by blatently ignoring it you could ultimately be shooting yourself in
the foot. (Un)fortunately the whole world is not an 80x86 running DOS in
real mode.
Yes DOOM is a particularly clever game, but the ingenious algorithms could
be implemented on another hard-ware platform - the 3D and texture
generation algorithms could be transfered to another platform with the
only code requiring revision being the code which directly handles the
screen access. Algorithms and data structures wherever possible should
run idependently of the hardware platform; these are what make a great
program. "Writing Solid Code" by Steve Maguire and published by Microsoft
Press contains a number of interesting portability anecdotes from
Microsoft's history: Although best known for their work on the PC, the
code for the Excel spreadsheet is common to both the PC and Mac versions.
>W>The presence of errors like this in books (and specifically in a book
> >annotating the ANSI C Standard) cast doubts on how well the rest of
> >the material can be trusted.
>It isn't an error. I only wish you all would pick on the authors who
>have source code upon source code listings in books that are blantantly
>error-prone! Nothing bothers me more than shelling out $29+ for a book
>and begin typing in the examples and find out the author or the editor
>goofed! At least Schildt's book seldom, if ever, have any errors!
The argument here is simply over what constitutes an error. I have
bought/borrowed books which contained listings which simply would not
compile let alone work (I have even found a diskette included with a book
with compilation errors in it?!?!). These are obvious errors which
anyone could spot (or at least the copiler does). More dangerous, surely,
are subtle errors which can remain undetected?
- Keith.
-----------------------------------------------------------------------
Keith A Goatman Medical Physics and Clinical Eng.
E-mail : K.A.G...@Sheffield.ac.uk Royal Hallamshire Hospital
Phone : (0114) 2766222 Ext. 2541 SHEFFIELD S10 2JF
Fax : (0114) 2713403 U.K.
-----------------------------------------------------------------------
xa2...@opie.bgsu.edu
>The argument here is simply over what constitutes an error. I have
>bought/borrowed books which contained listings which simply would not
>compile let alone work (I have even found a diskette included with a book
>with compilation errors in it?!?!). These are obvious errors which
>anyone could spot (or at least the copiler does). More dangerous, surely,
>are subtle errors which can remain undetected?
>Keith A Goatman Medical Physics and Clinical Eng.
I looked at a C book in a bookstore once that used "strict" interchangeably
with "struct" -- I believe it may have been a Waite Group book, although I'm
not sure. Flipping through the entire book, there were void-main()s and
"stricts" everywhere. They claimed portability, but I wonder what the hell
kind of C they were using...
-----
Morgan Deters
XA2...@opie.bgsu.edu
Lawrence Kirby
mp94...@stoat.shef.ac.uk "K A Goatman" writes:
>David Mohorn (david....@sourcebbs.com) wrote:
>
>>Let's C great games like DOOM and Wolfenstein written using ANSI
>>standard. Yeah! It ain't gonna work! ANSI is only good for stupid
>>text and standard file I/O operations. No graphics, no sound, no
>>hardware-level specific operations. In otherwords, it is just a
>>"stupid, generic program"!
>
>The tragedy of this posting is that oneday you may find out the hard way
>that the ANSI standard was _not_ compiled for the sheer pleasure of it and
>that by blatently ignoring it you could ultimately be shooting yourself in
>the foot. (Un)fortunately the whole world is not an 80x86 running DOS in
>real mode.
>
>Yes DOOM is a particularly clever game, but the ingenious algorithms could
>be implemented on another hard-ware platform - the 3D and texture
>generation algorithms could be transfered to another platform with the
>only code requiring revision being the code which directly handles the
>screen access.
I know it has been said before but it is worth repeating because it is
such a good example. The vast majority of Doom is written in ANSI C. I'm
sure that it is not a totally unrelated fact that Doom has now been ported
to many platforms from the original NEXT (DOS, Linux, Silicon Graphics
and now many games consoles). If ID hadn't used portable code from the
start this would have been an awful job.
Dennis Ritchie <7549-15328> 0112710
like DOOM and Wolfenstein could be written in ANSI C.
As has been mentioned here before, DOOM is almost
completely in ANSI C, with a tiny but time-intensive part of
the rendering algorithm in assembler. Of course the
interfaces to the screen, the keyboard, the mouse, and the soundbox
use interfaces that are not defined by ANSI and are platform-specific.
Probably some fraction of this is written in non-portable C and some
in assembler.
This is lesson 1: do as much as possible portably,
isolate the rest.
Here's the fun part of the story. I was looking through
old mail a couple of months ago and found a letter (sent in
March) from a person named John Carmack, who praised the lcc compiler
by Chris Fraser of our group and Dave Hanson of Princeton.
Carmack found lcc nicer than gcc ("This has saved me SO much time
(it was fun too)"). Having seen DOOM overtake most of
the leisure time in our lab over the summer, I was now
prepared to appreciate the significance of Carmack's letter.
So I sent him some mail acknowledging his thanks.
By return mail, we got a copy of the beta version of DOOM II.
This is lesson 2: portability often pays off in unexpected ways.
Dennis Ritchie
d...@research.att.com
Peter Seebach
>Subject: Re: Advanced Books
>M>Born to Code is C is GARBAGE
> >It was one of the 1st C books I bought...I tought it was great
> >until I actually tried to USE any of it...
> >it's not bug free, it's not commercial quality, it's not even
> >technically sound.
> >Very very bad buy... the book was easy to read and understand
> >SURE... but GIGO!
>I disagree. Maybe you are just a poor typist. I have not had any
>problems with any of the code. Since you stated that it was one of the
>first books you bought, I assume you were new to C programming and
>probably didn't know what you were typing; thus, this could be the
>reason for your attitude.
No, most experienced programmers think Schildt is incompetent too.
>Schildt is a very good author and I stand behind opinion.
How can you describe as "good" an author who, annotating the ANSI standard,
blatently contradicts it?
His work might well be wonderful if you planned to spend the rest of your
life ignoring and opposing standards documents for languages you wanted to
work in, and using only one computer, with only one compiler. Sadly, this
is a life only a few of us are qualified for.
> ş QMPro 1.53 ş Story of a Tagline thief: I came, I read, I stole.
Is it just me, or is everyone* who likes Schildt posting from some version
of QMPro? Do I detect a conspiracy?
(Or is this David Moron again?)
-s
--
Peter Seebach - se...@solutions.solon.com -- se...@intran.xerox.com
C/Unix proto-wizard -- C/Unix questions? Send mail for help.
David Mohorn
S>>M>Born to Code is C is GARBAGE
>> >It was one of the 1st C books I bought...I tought it was great
>> >until I actually tried to USE any of it...
>> >it's not bug free, it's not commercial quality, it's not even
>> >technically sound.
>> >Very very bad buy... the book was easy to read and understand
>> >SURE... but GIGO!
S>>I disagree. Maybe you are just a poor typist. I have not had any
>>problems with any of the code. Since you stated that it was one of the
>>first books you bought, I assume you were new to C programming and
>>probably didn't know what you were typing; thus, this could be the
>>reason for your attitude.
S>No, most experienced programmers think Schildt is incompetent too.
Such as? You?
S>>Schildt is a very good author and I stand behind my opinion.
S>How can you describe as "good" an author who, annotating the ANSI standard,
>blatently contradicts it?
You're resting your beliefs on one book. Do you have anything
substantiate your accusations?
S>His work might well be wonderful if you planned to spend the rest of your
>life ignoring and opposing standards documents for languages you wanted to
>work in, and using only one computer, with only one compiler. Sadly, this
>is a life only a few of us are qualified for.
Possibly.
S>> þ QMPro 1.53 þ Story of a Tagline thief: I came, I read, I stole.
S>Is it just me, or is everyone* who likes Schildt posting from some version
>of QMPro? Do I detect a conspiracy?
S>(Or is this David Moron again?)
Obviously I see we cannot have an intellectual conversation because you
must resort to name calling.
---
þ QMPro 1.53 þ Spaghetti code is computer lingo for job security.
Dan Pop Jr.
>Having seen DOOM overtake most of the leisure time in our lab over the
>summer, I was now prepared to appreciate the significance of Carmack's
>letter. So I sent him some mail acknowledging his thanks.
>
>By return mail, we got a copy of the beta version of DOOM II.
I work on Domain/OS, OSF/1, ULTRIX, HPUX, SunOS, Solaris, IRIX and AIX.
Is DOOM available for these systems? Is DOOM available for other systems
used by comp.lang.c readers? Is DOOM available for my PC which runs
Linux?
One more time: we were discussing about C here, not about DOOM. If you
have a DOOM comment, post it to alt.games.doom.
Dan
--
Dan Pop Jr.
ANAL, Retentive Division
Email: dan...@info.anal.ch
Peter van der Linden
> Having seen DOOM overtake most of the leisure time in our lab over the
> summer, I was now prepared to appreciate the significance of Carmack's
> letter. So I sent him some mail acknowledging his thanks.
To which Dan Pop Jr (Anal Retentive division) offers the rebuke:
> I work on Domain/OS, OSF/1, ULTRIX, HPUX, SunOS, Solaris, IRIX and AIX.
> Is DOOM available for these systems? Is DOOM available for other systems
> used by comp.lang.c readers? Is DOOM available for my PC which runs Linux?
>
> One more time: we were discussing about C here, not about DOOM. If you
> have a DOOM comment, post it to alt.games.doom.
Quite right, Dan.
This Dennis Ritchie character must be some kind of "New B" to bother
the cognescenti of comp.lang.c like that!
Good job you've been around here long enough to straighten him out.
Talk about cheek! Just who the heck does Dennis Ritchie think he is?
The inventor of C or something? The nerve of the guy!
--
Peter van der Linden lin...@Eng.sun.com
Will not work for anything; not hungry.
David Mohorn
D>d...@research.att.com (Dennis M. Ritchie) writes:
>>Having seen DOOM overtake most of the leisure time in our lab over the
>>summer, I was now prepared to appreciate the significance of Carmack's
>>letter. So I sent him some mail acknowledging his thanks.
>>
>>By return mail, we got a copy of the beta version of DOOM II.
D>I work on Domain/OS, OSF/1, ULTRIX, HPUX, SunOS, Solaris, IRIX and AIX.
>Is DOOM available for these systems? Is DOOM available for other systems
>used by comp.lang.c readers? Is DOOM available for my PC which runs
>Linux?
D>One more time: we were discussing about C here, not about DOOM. If you
>have a DOOM comment, post it to alt.games.doom.
I believe our original discussion involved ANSI-C and whether DOOM was
written using ANSI Standards. DOOM was mentioned because it was stated
that DOOM could not possibly be written in ANSI due to its advanced
technology and whatnot.
By the way, do you know you just just flamed? If you are reading this
group, you should be thanking him for his efforts for creating the C
language.
Peter Seebach
>Subject: Advanced Books
>S>No, most experienced programmers think Schildt is incompetent too.
>Such as? You?
Me. Chris Torek. Dan Pop. In fact, I believe every regular of this group
and comp.std.c that answers questions on a regular basis reccommends against
his books.
>You're resting your beliefs on one book. Do you have anything
>substantiate your accusations?
Yup. The fact that he uses the same patently illegal construct in all his
other books. The fact that he frequently gives as examples of portable C
code that fails on machines other than DOS boxes.
>S>(Or is this David Moron again?)
>Obviously I see we cannot have an intellectual conversation because you
>must resort to name calling.
Sorry, that one was uncalled for. :) Still doesn't mean Schildt's writing
is of any particular value or interest. Honestly, he's not a patch on Dennis
Ritchie, and given that Ritchie wrote a perfectly good book on C, I'm not
sure why anyone would read Schildt's frequently inaccurate books.
-s
> þ QMPro 1.53 þ Spaghetti code is computer lingo for job security.
*sigh* Sad but true.
Chris Torek
software, someone (probably Peter Seebach) wrote:
>... most experienced programmers think Schildt is incompetent too.
In article <14.210...@sourcebbs.com> david....@sourcebbs.com
(David Mohorn) writes:
>Such as? You?
In article <39rq56$n...@blackice.winternet.com> Peter Seebach
<se...@solutions.solon.com> responds:
>Me. Chris Torek. Dan Pop. In fact, I believe every regular of
>this group and comp.std.c that answers questions on a regular basis
>recommends against his books.
Now, Peter, you should know better than to speak for others without
asking first. :-) I do not know whether Schildt is incompetent,
careless, uncaring, ill-informed, malicious, or simply the victim
of a publisher who is some or all of the foregoing. I do, however,
know that he is wrong.
David Mohorn can believe whatever he likes, whether that be `the Moon
is made of green cheese', `the Earth is flat', or `Herbert Schildt's
C books are accurate'. Belief will not change the facts: these books
are riddled with errors---mostly minor errors, but errors nonetheless.
(This may be par for the course. A few years ago I sampled four
C books on the shelves of the local university bookstore. Not one
of them got arrays-vs-pointers right. K&R, H&S, and the FAQ are
good references these days; if other books disagree with them, any
errors are almost certainly in the other books.)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
Berkeley, CA Domain: to...@bsdi.com +1 510 549 1145
Wade Guthrie
>K&R, H&S, and the FAQ are good references these days
Actually, these days, I've been using the standard. If that ain't right,
nothing is! =^>
--
Wade Guthrie | "Here's to way *WAY* too many MIPS, vintage
wa...@nb.rockwell.com | sports cars, AD&D (first edition), and
I don't speak for Rockwell. | single malt whiskey aged in sherry casks."
James M. Stern
Seebach) writes:
|> [Long Schildt flame deleted.]
I haven't looked at the Schildt books as thoroughly as the rest of
you but in flipping through them in the bookstore I find that explanations
of various subtle but important points of the Standard are lacking. And of
course, there's always "v main (v)" -- I purposely don't spell it out because
I don't want to start _that_ thread again. :-)
But I will say one thing for him: His "The Annotated ANSI C
Standard" gives you a copy of the ISO Standard (His title is wrong!)
for less than it costs to buy that document directly.
Having said that, I should warn prospective readers:
* There's a misprint: One page of the Standard is missing and
another is duplicated in its place. (P.J. Plauger's "The Standard
C Library," a superb book, contains the missing page.)
* Ignore Schildt's annotations. Some are wrong.
* I don't know whether his latest edition contains the Technical
Corrigenda modifications to the Standard. The (Jan.?) C/C++
User's Journal lists them.
* "Annotated" is the only Schildt book I like enough to buy or
recommend. I recommend it for the Standard, not for Schildt's words.
|> > þ QMPro 1.53 þ Spaghetti code is computer lingo for job security.
|>
|> *sigh* Sad but true.
Then there's "lasagna code" -- too many layers. I coined "angel
hair pasta code" for programs even more tangled than spaghetti code.
I'm proud of that one.
|> --
|> Peter Seebach - se...@solutions.solon.com -- se...@intran.xerox.com
|> C/Unix proto-wizard -- C/Unix questions? Send mail for help.
--
Jim Stern -- These views are my own, not my employer's.
David Mohorn
T>(This may be par for the course. A few years ago I sampled four
>C books on the shelves of the local university bookstore. Not one
>of them got arrays-vs-pointers right. K&R, H&S, and the FAQ are
>good references these days; if other books disagree with them, any
>errors are almost certainly in the other books.)
Would you mind posting a few examples of these?
Chris Torek
I wrote:
>>(This may be par for the course. A few years ago I sampled four
>>C books on the shelves of the local university bookstore. Not one
>>of them got arrays-vs-pointers right. K&R, H&S, and the FAQ are
>>good references these days; if other books disagree with them, any
>>errors are almost certainly in the other books.)
In article <14.216...@sourcebbs.com> David Mohorn
<david....@sourcebbs.com> answers:
>Would you mind posting a few examples of these?
No, but first you will have to supply me with a time machine so I
can go back those years (and across the country to boot :-) ). I
cannot recall any of the titles with any accuracy, but I was in a
different bookstore last month or so, looking for `Expert C
Programming', and do not remember any of the current set of titles
as familiar, except for the classics: K&R (now in its 2nd edition)
and H&S (now in its third).
On the other hand, one can easily perform this test oneself: Take
a printout of the FAQ with you to the bookstore. Compare the book's
descriptions with answers in the FAQ. If the book disagrees with
the FAQ, the book is almost certainly wrong.
--
[Disclaimer: I have been put on codeine for a broken foot. This dulls
the mind, so my advice may be a bit less perfect than usual. :-) ]