Creating your first C++ program

We are now going to write some C++ source code. There is a very good reason why we are calling it the source code: it is the source from which we will build our binary executable code. The same C++ source code can be built on different platforms such as Mac, Windows, and iOS, and in theory, an executable code doing the exact same things on each respective platform should result.

In the not-so-distant past, before the introduction of C and C++, programmers wrote code for each specific machine they were targeting individually. They wrote code in a language called assembly language. But now, with C and C++ available, a programmer only has to write code once, and it can be deployed to a number of different machines simply by sending the same code through different compilers.

Tip

In practice, there are some differences between Visual Studio's flavor of C++ and Xcode's flavor of C++, but these differences mostly come up when working with advanced C++ concepts, such as templates.

One of the main reasons why using UE4 is so helpful is that UE4 will erase a lot of the differences between Windows and Mac. The UE4 team did a lot of magic in order to get the same code to work on both Windows and Mac.

Note

A real-world tip

It is important for the code to run in the same way on all machines, especially for networked games or games that allow things such as shareable replays. This can be achieved using standards. For example, the IEEE floating-point standard is used to implement decimal math on all C++ compilers. This means that the result of computations such as 200 * 3.14159 should be the same on all the machines.

Write the following code in Microsoft Visual Studio or in Xcode:

#include <iostream>  // Import the input-output library
using namespace std; // allows us to write cout
                     // instead of std::cout
int main()
{
  cout << "Hello, world" << endl;
  cout << "I am now a C++ programmer." << endl;
  return 0;      // "return" to the operating sys
}

Press Ctrl + F5 to run the preceding code in Visual Studio, or press + R to run in Xcode.

The first time you press Ctrl + F5 in Visual Studio, you will see this dialog:

Select Yes and Do not show this dialog again—trust me, this will avoid future problems.

The first thing that might come to your mind is, "My! A whole lot of gibberish!"

Indeed, you rarely see the use of the hash (#) symbol (unless you use Twitter) and curly brace pairs { } in normal English texts. However, in C++ code, these strange symbols abound. You just have to get used to them.

So, let's interpret this program, starting from the first line.

This is the first line of the program:

#include <iostream>  // Import the input-output library

This line has two important points to be noted:

1. The first thing we see is an #include statement. We are asking C++ to copy and paste the contents of another C++ source file, called <iostream>, directly into our code file. The <iostream> is a standard C++ library that handles all the sticky code that lets us print text to the screen.
2. The second thing we notice is a // comment. C++ ignores any text after a double slash (//) until the end of that line. Comments are very useful to add in plain text explanations of what some code does. You might also see /* */ C-style comments in the source. Surrounding any text in C or C++ with slash-star /* and star-slash */ gives an instruction to have that code removed by the compiler.

This is the next line of code:

using namespace std; // allows us to write cout
                     // instead of std::cout

The comments beside this line explain what the using statement does: it just lets you use a shorthand (for example, cout) instead of the fully qualified name (which, in this case, would be std::cout) for a lot of our C++ code commands. Some people don't like a using namespace std; statement; they prefer to write the std::cout longhand every time they want to use cout. You can get into long arguments over things like this. In this section of the text, we prefer the brevity that we get with the using namespace std; statement.

This is the next line:

int main()

This is the application's starting point. You can think of main as the start line in a race. The int main() statement is how your C++ program knows where to start; take a look at the following figure:

If you don't have an int main() program marker or if main is spelled incorrectly, then your program just won't work because the program won't know where to start.

The next line is a character you don't see often:

{

This { character is not a sideways mustache. It is called a curly brace, and it denotes the starting point of your program.

The next two lines print text to the screen:

cout << "Hello, world" << endl;
cout << "I am now a C++ programmer." << endl;

The cout statement stands for console output. Text between double quotes will get an output to the console exactly as it appears between the quotes. You can write anything you want between double quotes except a double quote and it will still be valid code.

Tip

To enter a double quote between double quotes, you need to stick a backslash (\) in front of the double quote character that you want inside the string, as shown here:

cout << "John shouted into the cave \"Hello!\" The cave echoed."

The \ symbol is an example of an escape sequence. There are other escape sequences that you can use; the most common escape sequence you will find is \n, which is used to jump the text output to the next line.

The last line of the program is the return statement:

return 0;

This line of code indicates that the C++ program is quitting. You can think of the return statement as returning to the operating system.

Finally, the end of your program is denoted by the closing curly brace, which is an opposite-facing sideways mustache:

}

Semicolons

Semicolons (;) are important in C++ programming. Notice in the preceding code example that most lines of code end in a semicolon. If you don't end each line with a semicolon, your code will not compile, and if that happens, you can be fired from your job.

Handling errors

If you make a mistake while entering code, then you will have a syntax error. In the face of syntax errors, C++ will scream murder and your program will not even compile; also, it will not run.

Let's try to insert a couple of errors into our C++ code from earlier:

Warning! This code listing contains errors. It is a good exercise to find all the errors and fix them!

As an exercise, try to find and fix all the errors in this program.

Note

Note that if you are extremely new to C++, this might be a hard exercise. However, this will show you how careful you need to be when writing C++ code.

Fixing compilation errors can be a nasty business. However, if you input the text of this program into your code editor and try to compile it, it will cause the compiler to report all the errors to you. Fix the errors, one at a time, and then try to recompile. A new error will pop up or the program will just work, as shown in the following screenshot:

Xcode shows you the errors in your code when you try to compile it

The reason I am showing you this sample program is to encourage the following workflow as long as you are new to C++:

1. Always start with a working C++ code example. You can fork off a bunch of new C++ programs from the Your First C++ Program section.
2. Make your code modifications in small steps. When you are new, compile after writing each new line of code. Do not code for one to two hours and then compile all that new code at once.
3. You can expect it to be a couple of months before you can write code that performs as expected the first time you write it. Don't get discouraged. Learning to code is fun.

Warnings

The compiler will flag things that it thinks might be mistakes. These are another class of compiler notices known as warnings. Warnings are problems in your code that you do not have to fix for your code to run but are simply recommended to be fixed by the compiler. Warnings are often indications of code that is not quite perfect, and fixing warnings in code is generally considered good practice.

However, not all warnings are going to cause problems in your code. Some programmers prefer to disable the warnings that they do not consider to be an issue (for example, warning 4018 warns against signed/unsigned mismatch, which you will most likely see later).