Printable View
I have just got admission into Computer Engineering and the first subject we are taught is C prog language.I dont want to faulter in the beginning.I would appreciate if somebody told me the kind of approach I should take and the books I should read to enhance my programming skills!
Rule #1: If they use "void main", get a new book or a new teacher.
Quzah.
>I would appreciate if somebody told me the kind of approach I should take and the books I should read
A few simple questions for instructors:
1) What is wrong with 'void main', if anything?
2) How can I flush the input stream?
3) *advanced* How do I portably tell if a computer is big-endian or little-endian at run-time?
4) Is gets() a good way to read string input?
5) What do you think of goto?
6) Is '*a ^= *b ^= *a ^= *b' a good way to swap two variables?
Here are the answers you should expect from someone knowledgeable:
1) Two things: There could be a naming conflict and the program will not run at all, or the return value will be garbage and cause undefined behavior.
2) There's no portable way to do this, but the best method is to use a loop which reads until either a newline character or EOF.
3) There is no portable way since not all machines use either big-endian or little-endian.
4) No, gets() is wrong because it doesn't check for boundaries of the buffer you pass to it. Every time you use gets() you risk writing into memory that you do not own, which is very bad.
5) goto should be avoided when possible because there are more structured ways to write code. There are times when goto is the best choice, but those times are few and far between.
6) No, this method is completely undefined because you modify a variable more than once between sequence points. A correct modification would be:
But this is still dangerous for anything but integer values, even then the integer values may break if the pointers point to the same locations in memory.Code:*a ^= *b;
*b ^= *a;
*a ^= *b;
Now a few things to look for in books:
1) void main
2) fflush ( stdin )
3) Heavy use of gets() or scanf() with no mention of fgets().
4) Code that doesn't check return values often.
5) Code that assigns to pointers that haven't been allocated memory, like so:
6) Any book by Herbert SchildtCode:char *p;
.
.
gets ( p );
7) Any book by Greg Perry
Some of these can be ignored if you know what you are doing, but for a beginner, any of the above means that you 'probably' cannot trust anything in the book and you should double check everything you read in it.
-Prelude
Prelude, I haven't read anything by Schildt, but in Perry's case, do you think it's possible that his ability to explain things from the point of view of new programmers makes up for his errors?
>do you think it's possible that his ability to explain things from
>the point of view of new programmers makes up for his errors?
If you teach incorrect things in a simple way, does that make them correct?
-Prelude
When you first learn programing you want to
learn how to program any language not just c.
I've seen some otherwise very knowledgeable people
use code that it void main so if your teacher uses it's not
grounds for dismisal. But if you write a book only about
c that contains void main then that's pretty bad.
>>void main so if your teacher uses it's not grounds for dismisal
Maybe not dismisal, but still a severe slapping. If someone is teaching you, they should teach you correctly. And the matter of void main vs int main in your wording simpy comes down to the teacher being too lazy to code a return value at the end of main. This is not a good excuse, imo. :)
If you are learning programming in general, not specifically C, then maybe your teacher should use pseudo code instead. That way, they can use whatever statements they want.
(just my 2 cents ;) )
Prelude, you can't seem to get past the errors. Errors can be corrected. Everyone in the world makes errors, unless they do absolutely nothing. The vast majority of what Perry teaches is good.
>Prelude, you can't seem to get past the errors.
I don't mean just typegraphical errors, I mean valid technical errors where the author is dead wrong in the explanation. I'm well aware that a book can contain mistakes after printing.
>The vast majority of what Perry teaches is good.
That is your opinion. Mine is different. You can't seem to get past that.
-Prelude
Prelude, the errors are a small part of the books. Shouldn't you also look at the good points.
Incidently, males and female write differently (unless they're really twisted).
Get yourself a Pocket C Reference Guide. It will be your constant companion and reading it will help learn faster.
I don't know who Greg Perry is, but I bet that Tom Swan wants to kick his ass.
>Shouldn't you also look at the good points.
I will concede that for some budding programmers, simplicity is more important than accuracy. I don't agree with this method of teaching, though if it works and the errors are corrected before bad habits are formed I see little wrong. The problem is that the errors usually are not corrected before the student gets into the habit of writing broken code.
>Incidently, males and female write differently (unless they're really twisted).
What bearing does this have on Greg Perry?
-Prelude
The best way to learn programming is to learn the concepts, try your hand at example code of those concepts.
The most important thing you can do is focus on concepts first
If you don't understand why you're doing something, you're sure as heck not going to understand how to do something.
Just one thing - if you are having trouble in your class, scream up and down and shout for H-E-L-P! Don't sit there like a potato - be very vocal if you need help from your lecturer/tutor. After all, you are paying for it and you are paying for their help!
If you want to learn C properly the book to read is:
The ANSI C Programming Language (second edition) by Brian W. Kerninghan and Dennis M. Ritchie
ISBN 0-13-110362-8
thankyou goodbye.