fredex wrote:
Basically this thread has went nuts. I followed up on a post and I mentioned the wrong name of a book of Herberts I like, and I still do by the way. It isn't C++ Bible, but "The Complete Reference: C++". One, this book doesn't use void main(void). The only mention of void in main is int main(void) or int main() (perfectly legal and logical). int main() directly from "The C++ Programming Language" Stroustrap and int main(void) and even int main()...in "The C Programming Language" Kernighan/Ritchie.On Sun, May 09, 2004 at 10:48:03PM -0500, Jeff Vian wrote:
fredex wrote:
On Sun, May 09, 2004 at 08:34:28AM -0500, Jeff Vian wrote:
fredex wrote:
On Sat, May 08, 2004 at 10:46:37PM -0400, Wade Chandler wrote:
Gene Heskett wrote:
On Saturday 08 May 2004 06:27, Trevor McNamara wrote:
Hello,
<snip>
Not to be a negative-sounding force here, but I would urge you to NOT ever use any of Herbert Schildt's books.
Mr. Schildt is a skillful writer, his writing is clear and lucid. He writes books on C and C++ that very easily and clearly lead you down the path to writing programs that are WRONG. he teaches bad practice in C and C++ in clear and easily understood ways, such that if you follow his advice you will learn his bad habits. one minor example is that he is one of the many people who incorrectly teach that it is permissible to declare main() as being of type void: void main (void) { ... } A little web searching, or spending a little time on groups.google.com reading comp.lang.c will find you plenty of examples of why his books are not a good way to learn C or C++. You can learn, in the same way, of many other books that do teach the language(s) correctly.
Please explain why main cannot be of type void.
1. Because the ANSI/ISO standard for the C language requires that main returns int.
2. And if that isn't good enough for you, if you don't care about standards, look at the practical implications. When you write a function:
I expected a reasoned discussion, not flaming.
I didn't (and don't) view this as flaming. I merely state it that way because I've seen discussion on this for years from people who aren't interested in what the standard says (they say "Well, it works for me on my compiler, so why shouldn't I use it???). So, I gave a practical reason for why it matters.
<snip>
While I agree main is most often typed to int for the purpose of returning a value designating completion with no errors or an error, there is no *requirement* for that.
ah, but there is. Again, the language standard requires that main return an integer.
So "why", you ask, "does the standard require main to return int?".
The original C standard was written to "codify existing practice". In many
environments (Unix, MS-DOS, probably other platforms) the return value of main is (or can be) used by the invoking program as a success or fail
status indicator. If the program doesn't return such a value the calling
program has no way to find out if hte program ran successfully or not.
true
True, you CAN write a broken program that doesn't return anything from
main, but it's still going to hand back SOME value to the invoking program
as its status. if you don't provide a value, the code that calls main is
going to return something anyway, most likely some garbage/arbitrary
value it picked up from the place main's return should have been, but wasn't (since main is expected to return something but didn't).
Understand, main() is NOT the first code to execute when a C program is
invoked. There's a chunk of "startup code", that is provided by the compiler vendor or a linkable library (invisible to the user) that
actually is invoked first, before main(). This code may do little in some
environments, or in other environments it may do a great deal of
stuff. But whatever it does, it (among other things) hands main its two
arguments, and receives an integer back from main. Changing the type of
main in your program does not change this code.
If you can provide *definitive documentation* of your statement that his teaching is wrong in the requirements for function main() I would like to see it.
See the language standard document.
I did look at that, all 550 pages of it.
OK, then, you surely saw the place(s) where it discusses main().
Or go ask this question in the newsgroup comp.lang.c where you'll either be ignored as a troll, or else will get flamed, depending on the mood this week.
Mr. Schildt, for all his skill as a writer (and he is good, no denying that!), is one (of many) people who perpetuate the myth that it's OK to play fast and loose with the language standard. The result is that so many people think that it IS OK to do so. But some day, somewhere in the future, doing one of these things he teaches will nail your program to the wall and you won't have a clue why it went wrong.
This as certainly not the first author of programming books to violate the standards in his methods. I first learned C in the days of
Did I say he was the first/only? No, I did not.
Borland's Turbo C compiler, (taught at Drexel University in Philadelphia), and the text book used in that class also ignored the return type of main(). ( yes, I still have the text and verified this )
Are you planning to be this hostile about ALL books that you don't happen to like.?
Again, it's not intended as hostility. It is intended as a warning to people who will take a book and learn from it, especially those books that teach incorrect programming. It's not the reader's fault that the book teaches them wrongly. However someone who does not already know C will not be able to discern those areas where the book teaches wrong practice. There are books around that carefully do not teach bad practice, many of them are recommended whenever this discussion comes up.
Again, the reason why I warn people about the books of Mr. Schildt is that they too often teach bad practice, book after book. (no I haven't read them all, but I have read some of them, and have seen plenty of disucssion from those who both know C and have read his books).
I've said all I want to say on this. Please do not continue to misinterpret what I'm trying to say (which is intended as a service to those who might be lead astray by books that teach incorrect practice).
Your point would be much better made without hostility, but reasoned agrument instead. I noted where the standards define main and I am satisfied with that. All I originally asked for was the location where it was defined that way, not a hostile diatribe.
And you got a pointer to the standard (I don't happen to have a copy of it HERE right now to which I can refer so I could have given you a more detailed reference). What you also got was a lengthy discussion of why it matters, it was NOT a diatribe. sorry if you misinterpreted it.
Goodbye.
Anyways, void main(void) is a bad example to use to make a point against an author without giving a book and page number. I have not seen where Schildt says to use or uses void main(void) in any book I've seen. In the complete reference I can turn to the index page 1003 look in M and find a reference to page 153 (main, return value from) (in the complete reference). Now, if I turn to page 153 I'll find (as I should):
"
What Does main() Return?
The main() function returns an integer to the calling process, which is generally the operating system. Returning a value from main() is the equivalent of calling exit() with the same value. If main() does not explicitly return a value, the value passed to the calling process is technically undefined. In practice, most C/C++ compilers automatically return 0, but do not rely on this if portability is a concern.
"
I guess he could have said one should always use return values, which would have been more correct according to many standards, however, I don't think this warrants an example of void main(void) in his name. Maybe you saw some typo or something that passed the editors, but I have never seen void main(void) in the book I'm speaking of nor any others of his...that I have personally seen.
I personally find "The Complete Reference: C++" to be a well written book, and it gets into details that plenty of books I have read do not. I know plenty of convert C to C++ programmers who use static instead of an empty namespace for hiding from the global scope because they don't know you can...apparently. So instead of typing a few characters they have to type static multiple times.
Contrast this book to "The C++ Programming Language". I happen to like Stroustrap's book, but it is a little hard to read at times. It isn't because the subject is very complicated either. It is just laid out a little strange (in my opinion), and isn't as nice to read as "The Complete Reference: C++". It just doesn't seem to flow as well is what I'm saying. This in no way means that Stroustrap's book isn't useful or doesn't have a lot of good info. I happen to like them both, but I don't believe Schildts writing is bad nor incorrect either.
Remember that I'm talking about "The Complete Reference: C++" as the example here.
Wade
