resources for learning c
i have recently started learning C programming by self-learning
though there are lot of resources available to learn, i cannot find any
good resources to programming problems for beginners.
i have just completed loops today and cannot find any relevant programs to test and write programs.
if you guys can suggest any good book or website for the same purpose that be a great help.
I am using gcc for compiler on Ubuntu 14.04 on VMware.
I am normally very reluctant to recommend beginners' books since I had been at that stage so long ago (over 20 years) that the books I used are no longer in print. Plus I was already proficient in a few other languages so I wasn't an actual beginner.
I would expect any book that you'd be using to include programming exercises. If that is not the case for you, then here are a couple well-known candidates:
1. The C Programming Language; Second Edition by Bryan Kernighan and Dennis Ritchie, the designers of C. The first edition was literally the de facto programming manual for the language. It has plenty of exercises. It is a small book, but it is filled with concentrated information which may be more difficult for a beginner to digest -- again, I'm too far removed from that beginner state to be a fair judge. It is a classic which every C programmer should eventually keep on his bookshelf.
2. Schaum's Outlines Programming with C by Bryon Gottfried. My copy was $17 US and I'm fairly certain that it's still less than $20 US. It is a very good tutorial and reference and has programming problems with the answers to some of the problems in the back of the book. In answering some of the tricker problems on this forum, I have often found the answer in this book.
When you use gcc, be sure to turn warnings on. I always compile with the -Wall option which turns on all warnings. Others recommend using -Werror which treats warnings as errors, which is the attitude that you should always have towards warnings.
Never ignore warnings. Warnings are much more important than error messages. Warnings are telling you that you probably made an error, in which case your code is broken and that, even though it generated an executable, that executable most likely will not do what you wanted it to do. Never run a program that throws warnings, since it is broken and will produce unexpected results. Do not try to debug a program that throws warnings, because the unexpected results you're encountering could very well be due to what the compiler is warning you about. Always get your program to compile cleanly first (ie, no errors and no warnings) before you try to run it and to debug it. Always turn warnings on and up! And never ignore warnings.
July 10th, 2014, 02:30 AM
Thank you dwise1_AOL for your help.
I have just started programming and most of the problems that I have encountered, I feel are a bit heavy for me.
I'll be sure to check out the books you have recommended, maybe download an eBook for quicker access.
I am using C/C++ programming websites tutorial for learning and couldn't find many questions to practice, hence the question.
Also I just recently started to use Ubuntu and its terminal for compiling using GCC.
I googled about the wall command and understand that it can help me with errors as you mentioned.
It would be really appreciated if you can explain me about it a bit more into detail and how to use it, as using a terminal is a new thing for me.
Thank you for the help you provided.
July 10th, 2014, 10:56 AM
Bear in mind that the Kernighan and Ritchie (K&R) book was written by high-power computer scientists -- basically, gods -- who were involved in designing UNIX. As a result, their book was written for people who already think like a programmer. They don't spend time explaining basic software concepts because they expect you to already know them. That is one reason why the book is so small and yet contains so much information, because that information is in a concentrated form; they will say in one paragraph what a beginner's book would need the better part of a chapter to cover. I have not done any of the book's exercises since I already knew how to program (FORTRAN, BASIC, PL/I, Pascal) and I already had my own projects to practice with, both personal and work-related. From what I've seen though, the exercises cover a wide range of practical programming techniques that are good to know -- if we were to use a foreign language analogy, those exercises would be like a phrase book that shows you how to say the most common things in that language and how to handle the most common situation in that language. Plus the book is authoritative, since K&R quite literally wrote the book on C.
The Schaum Outline should be much more accessible to a beginner. It explains the concepts and provides many examples, plus illustrations that explain things like arrays, pointers, and file I/O. Its chapter on pointers, a vitally important concept in C and C++, is one of the best I've seen (my C teacher in 1990 handed out xerox copies of it to class); at the end of that chapter is a long list of declarations involving pointers.
So if you get the K&R book (make sure it's the second edition with the big red "ANSI C" stamped on the cover; the language had just gone through significant syntax changes with the ANSI standard of 1989), try reading the section of text leading up to that section's exercises and if you don't quite understand it then also refer to another more beginner-friendly resource.
The first half of my professional experience (32 years) was spent almost entirely on the command line, so it's second-nature for me (having learned touch typing in junior high also helped). To this day, the first app I open in the morning is the command line. That makes me the worst person to tell somebody how to use it, because it's so natural to me that I can have difficulty understanding why someone doesn't understand it. This will work best if you ask specific questions about specific problems that you encounter rather than ask general questions.
First, understand that in GUIs you can also use the Clipboard with the terminal window. That means that you can copy and paste what's in the terminal. This will come in handy when you have questions about unexpected output or about warnings or errors that you're getting, since you are able to copy what's displayed in the terminal and paste it to your messages on this forum. I'm not sure about the details of how to do that under Ubuntu, but I do it all the time with Windows Cmd Prompt consoles.
Does your general question concern how to use gcc? First you cd (ie, chdir) to the directory that your source file is in. Let's assume that your source file is myprog.c . You would compile it thus:
gcc -Wall myprog.c
If successful, that would generate an executable with the default name of a.out . You would then run a.out thus:
You need that ./ to tell bash (the shell that terminal runs) where a.out is, which is to say in the current directory. Shells maintain a PATH list with is a list of directory paths that it is supposed to search through to find the executable that you want to run. gcc's path is in that list, which is how you're able to run it from any directory. You should be able to use the where command to find where a particular program is kept. By default and for security reasons, bash does not look in the current directory unless you specifically tell it to. You could add the current directory ( . ) to the end of the path (not at the beginning, since that would be a security hole). Or you could simply use ./ to tell bash that the program is in the current directory. BTW, this is a fairly common problem for first-timers. OTOH, MS-DOS would always automatically look in the current directory first before turning to PATH, so it's also a very common problem for DOS'ers migrating to Linux for the first time; been there, got bitten by that.
Another important directory name is .. , which refers to the parent directory. Learn about and become very familiar with the concepts of directories, sub-directories, directory trees, and directory paths. From my MS-DOS experience, I learned to visualize how everything is laid out in the directory system.
If you want to give your executable a name other than the default a.out, then use the -o option. If you want the executable of myprog.c to be myprog, then that would be:
gcc -Wall myprog.c -o myprog
You will notice that a program's options are indicated by a minus sign. There are also whole-word options which are indicated by a double minus; eg, --help. If you invoke gcc --help then you will get a list of the options.
Look for a tutorial on using bash. A tutorial on shell scripting might also be useful.
Hope I didn't bury you in all that. Maybe that's an object lesson in the importance of asking specific questions (grin).
Last edited by dwise1_aol; July 10th, 2014 at 10:59 AM.
July 10th, 2014, 11:19 AM
I forgot to talk about warnings and error messages. The good things are that they tell you what kind of a problem the compiler encountered and the line number where that problem was found. The bad thing is that the meaning of the message is not always clear to a beginner.
At first, you will have difficulty understanding what the message is telling you. With time and experience, you will learn what kinds of mistakes cause which particular messages. As you are learning, keep these things in mind:
- Some messages should be common-sensical enough to figure out, so think about what it's saying. If it complains that a variable has not been declared, then check whether you had declared it or whether you had misspelled it by mistake (remember that C is case-sensitive, so num and Num are two different identifiers). If it says that printf or scanf has too many or not enough arguments, then verify that you have exactly the number of arguments that the format string requires. If it says that it couldn't open a particular header file, then verify that you had spelled it correctly. If you stop and think, you should be able to figure a lot of the messages out.
- The message has a line number. Look at the line in the source and try to figure out what's wrong about it. Sometimes, the mistake had happened before that line (eg, you failed to prototype a function, so first you get a warning by calling an undeclared function and then, since C assumes by default that it's an int function that takes an int argument, when you actually define the function later on you will get a warning or error because you just "redefined" that function). Or you left out a semicolon of a quote mark to close a string, in which case the problem isn't detected until several lines later. So go the the line that's cited as where the problem is and then work your way up. Always remember that the compiler starts at the top and works its way down.
- If you still cannot figure it out, then post the question here. Be sure to copy and paste the exact message as it appears on your system. This is very important. Do not try to paraphrase it, because you could lose the meaning in the process. Give us the exact message. Also post the portion of the program that contains the offending line of code. Use code tags to preserve your code's indentation., AKA "formatting". Unformatted code is unreadable.
Here is how you use code tags:
[code] insert your formatted code here using copy-and-paste [/code]
July 10th, 2014, 08:46 PM
Thank you again dwise1_aol for the help you provided.
i downloaded the 2 edition of Programming in C, though going through it briefly i think i should first have some refer to some other book before returning to it.
looking for Schaum now. Also got a copy of C, the complete reference from my library. think it should suffice for now.
Also thanks for explaining what each command does while compiling using gcc, as i was using them but thought that the -o command was necessary for the compilation.
i got that format from googling how to compile c programs using gcc.
thanks for pointing it out and also telling me how to use the code tag in the forum, it would come as a great help.
though got a little lost about what you were telling about directories, but after a quick google search, i think its clear a bit now.
also i believe with experience i would understand them better, so getting back to programming now.
Thanks for your help. I would try to be specific about the problem, next time i face them.
thanks for your valuable time. Greatly helpful, your suggestions have been.