Implicit Type Conversion in C++

Every function call is a small handoff. The caller supplies values, and the function receives them through its parameters. Usually this handoff happens without any thought, because the value you supply already has the type the function expects. Sometimes it does not match, and the compiler has to decide what to do. This article follows what the C++ compiler does at that handoff, and why a mismatch is caught before the program ever runs.

The goal is a habit. When you read a call, you should be able to say three things: which value reaches the parameter, what type that value has at that moment, and whether the compiler will accept it. The running example throughout this article is a single library function, sqrt, which takes a double and returns the square root of that double.

Before reading the explanation, make a prediction about two calls to sqrt. The first passes the integer literal 2. The second passes a string literal. Decide which one you expect to compile, and what kind of problem you think the other one will cause.

The rule that governs argument passing is short. The way a value is handed to a parameter follows the same rules as the way a value is used to initialize a new variable by copy. In other words, if you already understand how a variable is initialized from a value of a different type, you already understand how a function parameter receives an argument.

Two things happen under that rule. First, the compiler checks the argument's type against the parameter's type. Second, if the types differ and an implicit argument type conversion is possible, the compiler performs that conversion when it is necessary. Nothing in this process requires you to write the conversion yourself. The compiler supplies it, and the parameter ends up as a new object of the parameter's type.

The source illustrates the first call with sqrt(2). The comment in the code describes the call as passing the argument double{2}, which is the value 2 presented as a double. The programmer wrote an int-looking literal, and the compiler supplied the double form that the parameter needs.

The second call in the source is the one that fails. A call to sqrt with a string literal cannot be repaired by conversion, because there is no implicit conversion from a string to double. The compiler reports an error, and the program does not get built. The diagram below follows the same decision that the compiler makes for any argument, and shows why the string branch ends in an error rather than a converted value.

The checking happens at the call site, against the declared parameter type. The body of the function is not consulted to decide whether the call is legal. This is why the diagnosis of a bad call points to the line where the call was written, rather than to some line inside the function.

A function declaration tells the compiler the name, return type, and parameter types of a function. It may also include argument names. Those names help a human reader understand what each parameter means, but the compiler does not use them, unless the declaration is also a function definition. The diagram below marks which parts of a declaration form the function's type.

A function's type is its return type together with its argument types. Names are not part of it. The source's example is get. Its return type is double, and its argument types are a reference to a const vector of double and an int. Its name, vec and index, is not part of the type. The type therefore reads as double taking a const vector-of-double reference and an int.