Now that we have created
some variables, we would like to store values in them. We do that with
an assignment statement.
sFirstName = "Mike"; // assign string "Mike"
cFirstLetter = ’a’;
// give cFirstLetter the value ’a’
iHour = 11; // assign the value 11 to
iMinute = 59; // set iMinute to 59
dSeconds = 2.5; // give dSeconds the
This example shows
four assignments, and the comments show several different ways people
sometimes talk about assignment statements. The vocabulary can be
confusing here, but the idea is straightforward:
When you declare a
variable, you create a named storage location.
When you make an
assignment to a variable, you give it a value
A common way to represent variables on paper is to draw a box with the
name of the variable on the outside and the value of the variable on
the inside. This kind of figure is called a state diagram because is
shows what state each of the variables is in (you can think of it as
the variable’s “state of mind”). This diagram shows the effect of the
five assignment statements:
Note: You can also combine these shapes with other flow symbols to
actually diagram your program flow, however that will not be discussed
in this book.
I sometimes use different shapes
and colors to indicate different variable types. These shapes should
help remind you that one of the rules in C++:
A variable has to have the same type as the value you assign it. For
example, you cannot store a string in an int variable.
The following statement
generates a compiler error:
iHour = "Hello."; // WRONG !!
There is one
source of confusion is that some strings look like integers, but they
are not. For example, the string
, which is made up of the characters 1, 2 and 3, is not the same thing
as the number
. This assignment is illegal:
iMinute = "59"; // WRONG!
Sometimes values can be converted to another type automatically though.
For example you can assign all these
values to strings and they will be converted automatically. Please keep
in mind that this is a WCM C++ extension and you cannot do the same
thing in classic C++:
string sConverted =
sConverted = 5; // sConverted will be "5"
after this statement
sConverted = 5.0; // sConverted will be
"5.000000" after this statement
sConverted = 'a'; // sConverted will be "a"
after this statement
You can see from this example that it is possible to
assign a value to variable immediately after a declaration:
string sConverted = "some text";
You can also see that it is legal in C++ to make more than one
assignment to the same variable. The effect of the second assignment is
to replace the old value of the variable with a new value. This kind of
multiple assignment is the reason I described variables as a container
for values. When you assign a value to a variable, you change the
contents of the container, as shown in the figure:
There are also other cases when values can be converted to
another type automatically. For example integer values can be converted
do double and vice versa:
double dVal = 5;
// dVal will be 5.0 after this statement
int iVal = 5.72;
// iVal will be 5 after this statement
When you assign a
floating-point value to an integer variable the values are rounded
Another example is
which can be converted to
int iNumber = 'a';
The above statement will assign
is the number that is used internally by C++ to represent the letter
. However, it is generally a good idea to treat characters as
characters, and integers as integers, and only convert from one to the
other if there is a good reason.
Automatic type conversion
is an example of a common problem in designing a programming language,
which is that there is a conflict between formalism, which is the
requirement that formal languages should have simple rules with few
exceptions, and convenience, which is the requirement that programming
languages be easy to use in practice.
More often than not, convenience wins, which is usually good for expert
programmers, who are spared from rigorous but unwieldy formalism, but
bad for beginning programmers, who are often baffled by the complexity
of the rules and the number of exceptions (fun note: it is also bad for
programs, such as aircraft flight controls, that must be extremely
reliable since the ambiguities may give problems at very inconvenient
times. For such applications, more strictly typed languages are often
used). In this book I have tried to simplify things by emphasizing the
rules and omitting many of the exceptions.