Initializing Variables

Most beginners assume that when they declare a variable and give it a value, the variable holds exactly the value written in the code. For whole numbers and matching types, that assumption works without trouble. It starts to fail when the value you write does not fit the type you declared. A variable declared as an int that is given a decimal literal such as 7.2 does not simply keep 7.2, and it does not always refuse to compile. The actual behavior is more specific, and this article traces it step by step so you can predict it and guard against it.

The article follows one question throughout: when a value is placed into a variable, what exactly happens to it, and how can a silent change slip past you? To answer that, we first need a precise idea of what initialization is.

Declaring and initializing are usually written as a single statement, which is why the two ideas blur together for beginners. The declaration supplies the name and the type. The initialization supplies the first value. Because a value is supplied at the same moment the name is introduced, the practical discipline is to avoid introducing a name until you have a suitable value for it.

Most variable definitions name the type before the variable. Auto offers a different route: you leave the type out and let the value on the right-hand side decide it. The rule is simple to apply once you look at the right-hand side first. Whatever kind of value the initializer produces is the kind of value the variable will be. A literal such as true has a bool type, a character in single quotes has a char type, a whole number like 123 has an int type, and a number with a decimal point such as 1.2 has a double type.

The same idea reaches beyond literals. Consider a declaration whose initializer is a function call, such as auto z = sqrt(y);. The variable z does not get a type from anything you chose by looking at z. Its type is whatever sqrt(y) returns, and the compiler copies that type onto z. Because the function call is the source of the information, auto is not limited to literal values; it applies to any expression that produces a value.

Conversions are where surprises usually come from. When the type written on the left does not match the type of the value on the right, the value may be changed to fit, and that change may lose information. An auto declaration cannot produce that mismatch at the point of the declaration, because auto does not change the type of the value. The variable's type is the type of the initializer, so the value is stored in a variable of exactly that type. This is the sense in which auto avoids a conversion at the start of the variable's life.

The default approach is to use auto when you have no specific reason to mention the type. Auto is the everyday choice, and an explicit type is the exception that needs a justification. Two kinds of justification appear in the source. The first is scope: when a declaration sits in a large scope, naming the type makes the variable's kind visible to a reader who is far from where it was introduced. The second is precision: when the exact range or precision of the value matters, naming the type makes that requirement explicit.

Auto also helps you avoid redundancy and avoid writing long type names. The source notes that this is especially important in generic programming, where the exact type of an object can be hard for the programmer to know and the type names can be quite long. In that setting, auto lets you define the variable without first working out and typing the full name.

C++ offers two notations for giving a variable its starting value. The first is the = form, which is the traditional style and dates back to the C language. The second is a universal form based on curly-brace-delimited lists, sometimes called the initializer list form. For ordinary cases, both notations produce the same result. The difference appears when the value does not match the type.

The source gives clear guidance on which to prefer. The = form is acceptable and familiar, but when in doubt, use the general braced form. Its most practical benefit is the protection it gives against conversions that lose information, which the next sections examine.

A narrowing conversion, such as double to int, loses information. Narrowing conversions are allowed and are applied implicitly, so they can change a value silently. The language does not stop you from writing them with the = form. The source describes the resulting problems as a price paid for compatibility with C. In practice, the compiler will often accept code whose value has quietly changed, so safety has to come from how you write the initialization.

The lost portion in the prediction above is the 0.2. Nothing in the = form warns you that this happened. The stored value is a valid int, so the program carries on, and any later calculation that depends on the original decimal will be wrong with no error message pointing back to the declaration. The value you see is not the value you wrote, and the mismatch is invisible at the moment it occurs.

Read the diagram from left to right. The original double value on the left has a whole part and a fractional part. The int on the right keeps only the whole part, so the fractional part is the information that disappears. The same reasoning explains the prediction: 7.2 becomes 7 because the 0.2 is discarded.

The braced form rejects narrowing conversions, turning a silent value change into a compile-time error that points at the problem. The three initializations below all try to place the same decimal value into an int. Their results differ, and the differences are the reason the braced form is recommended when you are unsure.

The pattern is that the braced form turns a silent problem into a visible one. The compiler refuses the narrowing rather than applying it. This is the practical reason the source recommends the general braced form whenever you are in doubt about whether a value fits its type.