Thursday, October 10, 2013

C++ Tutorial #5: More Grammar Rules/ERRORS!

Now that you've seen your first C++ program, you're starting to get a feel for what this language looks like.  Again, it's just like any other language—English, Spanish, Russian, Japanese, etc.  All languages have a few things in common: they have rules on spelling, grammar, mechanics (like punctuation), and overall structure (or syntax).


The main component of any language, including C++, is the vocabulary.  A language is built with words, some being more important than others.  The really important words in C++ are called keywords.  Here's a list of some of them: 

Words that were left over from the older C language (but are still used in C++): 
auto         double     int             struct
break       else        long           switch
case         enum      register     typedef
char         extern     return       union
const        float       short         unsigned
continue   for         signed        void
default     goto       sizeof         volatile
do             if            static        while

Words that are specific to C++:
asm                false             private                  throw
bool               friend            protected              true
catch              inline            public                    try
class               mutable       reinterpret_cast   typeid
const_cast      namespace  static_cast            using
delete             new             template               virtual
dynamic_cast operator       this

(Sorry. I tried to line those up the best I could, but Blogger was not on my side.)

Now, do you need to memorize all these right away? No. In fact, in my programming experience, most I haven't even used. You'll begin to learn them and the context in which they're used as time goes on.

Having said that, I do recommend you print this list for future reference. The reason? All of these words are reserved words, meaning they can only be used for their intended purpose (for example, int can only be used to declare something as an integer number). Reserved words can't be used for naming functions or variables (which will be discussed somewhere in the next couple of posts), so keep that in mind when naming stuff in the future.

Questions or Comments?

Comments are essentially digital Post-It-Notes you put in your programs. You can insert them at any point and in as many places as you want in your source code files. The idea of using code Post-It-Notes to remind yourself of what you’re doing may sound silly to you if you’ve only programmed very small files like the one I used as an example in the last post. However, if you’re writing an operating system, which can take months if not years to complete and debug, you need little reminders in your code to help you out. However, how do you insert such reminders without the compiler thinking it’s some crazy part of the code?

// Like this.
// Two front slashes for each comment.

// Anything in front of the two slashes is ignored
// by the compiler.  However, each line of comment
// ends when the line ends, so you have to type
// another two slashes if you want another line.
// You can group many lines of comments together.
// Comments or not, compilers don't like long lines of code.

You can use comments to disable parts of your code that you don’t want/aren’t working but would be inconvenient to remove.  However, be sure that you don't comment out anything important, and if you want to bring back some commented code into a program, you have to "un-comment" it (removing both slashes from the line, which in turn "un-comments" the whole line).

All Major Components of the C++ Language Explained Briefly

Keywords are like words, which must be used in context.
Operators and other symbols are used for numerical operations or act as punctuation (+, <<, ;)
Parentheses, or parens, group certain instructions for the words. You'll do more work with parentheses later.
Statements are what all these words and instructions are together, ending with a semicolon.
cout << "Hello world!" << endl;
int age = 18;
Curly braces group parts of a program, usually functions. { }
Comments don't add anything to the program itself and are ignored by the compiler, but are important because they are notes and reminders for the programmer and anyone else reading the code.
Everything together is the language’s syntax (how a language is put together).

The Most Commonly-Forgotten Rules of the C++ Language

1) Braces come in pairs.
2) All statements end in a semicolon.
3) Spaces and indentation are optional in the text editor (like Dev-C++), but not in command lines.
4) A main() function is required. That’s the shortest a C++ program can be.
5) C++ is written mostly in lowercase, and it is case-sensitive.

What Happens if You Break the Rules: ERRORS

I've heard some programmers joke that the process should be called debugging instead of programming because it’s just about guaranteed that your program will have some problem with it, no matter how little code there is.  With the exception of seeing it while you’re writing the source code, the earliest you might catch a mistake is when you go to compile it and something goes wrong.  You might also catch an error later, as creating a finished product involves many steps. There are four main types of errors:

Compiler Errors: These are considered the “easy errors.”  When you go to compile the program, an error in code makes it so that compiling cannot take place.  The final product (the .exe file) is not made, and you are informed exactly where the error is and what general problem it is (for example: program.cpp: in function ‘main’: program.cpp:6 parse error before “return”)

In this case, you are told what program erred (as if you didn’t already know), in what function it occurred, in what line of code it occurred, and what type of error it was and where exactly it was. (In this case, I had written a cout statement but forgot to put a semicolon at the end. Oops!)

Linker Errors: These usually have to deal with misspelled commands or a problem with linking many source code files (if your program is that complex). The compiler doesn’t care (all it does is translate), but the linker can’t put the pieces of the program together if there are misspelled commands—after all, how’s it supposed to know what that piece is supposed to do?  These errors are more difficult to figure out because the error messages are quite vague, usually talking about an “undefined reference to [misspelled word]”.  No line number is given.  That means you just have to look for the misspelled word outlined in the error message.  Grr.

Run-Time Errors: The compiler and linker are both happy, and the file is made.  However, for some reason when you go to run it, it shuts down immediately or unexpectedly partway through the program’s course.  These errors aren’t the easiest to spot but they’re not the hardest, since you can tell at what point in the program’s course the error occurs.

Bugs: These are the worst. Not only are the compiler and linker happy, but the program can still run just fine.  The program is still a program and there’s nothing technically wrong with the code.  The problem?  It doesn’t do exactly what you wanted it to do.  Maybe it does some math wrong, or it doesn't display with the neat pretty formatting you wanted.  This type of error requires intense vigilance and critical thinking to be found.

Lastly, two types of error messages:

Warnings: the file is still created but there’s something about it that the compiler and/or linker doesn’t like. It means that they found something that, in context, looks unusual or suspicious. It might be a bug, or it might be them being touchy. But the program will still run—just, in the case of a bug, perhaps not exactly how you wanted it to.

Critical (or fatal) errors: at this point the compiler and/or linker refuses to finish the job. This means there is a true error in coding and not just something that looks suspicious, and you need to fix it before the final product can be created.

And there's your grammar lesson for the day.  Really pour over this post and become familiar with its contents, because this is the kind of stuff you'll be dealing with when you're modifying and debugging your programs.

No comments:

Post a Comment