Wrapping Up Type Systems and Automatic Type Inference

This chapter had one running question behind every lesson: when a value of one type shows up where another type is expected, what does the compiler do about it? The answer splits neatly in two. Either the compiler resolves the mismatch on its own, or you resolve it for the compiler with a cast. Everything else in the chapter was detail hanging off that split.

Rather than replay each lesson in order, this recap consolidates the chapter into a handful of tables you can scan, with one short program per idea to anchor it.

The Chapter at a Glance

Lesson The one thing it established
Type Inference Terminology The vocabulary: conversion, promotion, narrowing, cast, alias, deduction
Automatic Type Conversions in C++ The compiler converts silently whenever a mismatch is resolvable; otherwise you get a compile error
Numeric Type Promotions Some narrower types widen to int or double with no loss at all
Converting Between Numeric Types Every other fundamental-to-fundamental conversion, some safe, some lossy
Safe Initialization and Narrowing Conversions Brace initialization refuses to hide a lossy conversion from you
Mixed-Type Arithmetic Conversions Binary operators need matching operands, so one side gets converted first
Manual Type Casting Techniques static_cast is how you say "yes, I meant that conversion"
Creating Type Aliases for Clarity An alias renames a type without creating a new one
Automatic Type Deduction with auto The initializer decides the variable's type, minus const and references
Function Return Type Deduction The return statements can decide a function's return type, and usually should not

Who Asked for the Conversion?

A type conversion produces a value of one type from a value of another type. The dividing line is who requested it.

Implicit type conversion Explicit type conversion
Also called Automatic type conversion, coercion Casting
Triggered by A type mismatch the compiler notices A cast you write
Who decides The compiler You
When it fails Compile error, because the compiler cannot work out a conversion Compile error, or a value you did not want
Visible in the source Often not Always

Implicit conversion happens whenever one type is expected but another is supplied: passing an argument, returning a value, initializing a variable, or feeding a binary operator. If the compiler can work out how to get from the source type to the destination type, it does so without comment. If it cannot, compilation fails.

The Standard Conversions

Everything the compiler already knows how to convert on its own comes from one fixed list, the standard conversions. Three families on that list matter here.

Family What it covers Value-preserving?
Numeric promotion Certain narrower types widening to int or double Always
Numeric conversion Every other conversion between fundamental types Sometimes
Usual arithmetic conversions The rules that give a binary operator two operands of one type Depends on the operands

A numeric promotion widens a small numeric type to the size the processor works in most comfortably, which is int for integral types and double for floating point. Promotions are value-preserving: the destination type can represent every value the source type can hold, so nothing is lost or rounded. Integral promotions and floating-point promotions are the two halves of this family.

Widening is not the same as promoting
Not all widening conversions are promotions. Promotions are a specific list written into the standard. Widening an int to a long makes the type bigger, yet it is a numeric conversion, not a promotion, because long is not one of the promotion targets.

Whatever the promotion list leaves out lands in the numeric conversion bucket instead: still one fundamental type going to another, but now with no safety guarantee attached. Plenty of them are harmless. The ones that may lose value or precision get their own name, narrowing conversions, and they go wrong in three ways: a fractional part gets truncated, a value falls outside the destination range, or precision is silently rounded away.

Here are the first two families side by side, with the third one waiting in the next section:

#include <iostream>

int main()
{
    short sensorReading{ 812 };
    int widened{ sensorReading };    // integral promotion: short to int

    float rainfall{ 6.25f };
    double widerRainfall{ rainfall }; // floating-point promotion: float to double

    double litresPerHour{ 148.9 };
    int truncated = litresPerHour;    // numeric conversion: double to int, fraction lost

    std::cout << "widened: " << widened << '\n';
    std::cout << "widerRainfall: " << widerRainfall << '\n';
    std::cout << "truncated: " << truncated << '\n';

    return 0;
}

Output:

widened: 812
widerRainfall: 6.25
truncated: 148

The third line uses copy initialization deliberately. Rewrite it with braces and the compiler stops being quiet about it. The version below is broken on purpose:

#include <iostream>

int main()
{
    double litresPerHour{ 148.9 };
    int truncated{ litresPerHour }; // narrowing conversion, flagged here

    std::cout << truncated << '\n';

    return 0;
}

The platform compiler reports:

s.cpp: In function 'int main()':
s.cpp:6:20: warning: narrowing conversion of 'litresPerHour' from 'double' to 'int' [-Wnarrowing]
    6 |     int truncated{ litresPerHour }; // narrowing conversion, flagged here
      |                    ^~~~~~~~~~~~~

That diagnostic is the whole point of list initialization. Copy initialization accepts the loss without a word; brace initialization makes you acknowledge it.

Make intended narrowing visible
When you genuinely want the truncation, write static_cast<int>(litresPerHour). The braces then have nothing to complain about, and the next reader can see that the loss was a decision rather than an accident.

When Operands Disagree

An operator like * or < has no way to work across two different types; it needs one type to operate in. When the two sides disagree, the compiler applies the usual arithmetic conversions: a ranked set of rules that converts one side, or occasionally both, until they match, generally settling on whichever type covers the wider range of values.

This is also the clearest place to see what auto deduces, because auto takes the type of the initializer after all conversions have already been applied.

#include <iostream>

int main()
{
    int rainyDays{ 9 };
    double litresPerDay{ 216.5 };

    auto weekTotal{ rainyDays * litresPerDay }; // int operand converted to double
    auto fullBuckets{ rainyDays / 2 };          // both operands are int

    std::cout << "weekTotal: " << weekTotal << '\n';
    std::cout << "sizeof(weekTotal): " << sizeof(weekTotal) << '\n';
    std::cout << "fullBuckets: " << fullBuckets << '\n';
    std::cout << "sizeof(fullBuckets): " << sizeof(fullBuckets) << '\n';

    return 0;
}

Output:

weekTotal: 1948.5
sizeof(weekTotal): 8
fullBuckets: 4
sizeof(fullBuckets): 4

rainyDays * litresPerDay mixes int with double, so the int is converted to double, the multiplication happens in double, and the result is a double. auto then deduces double. In the second line both operands are already int, no conversion is needed, and integer division discards the remainder.

Mixing signed and unsigned
The usual arithmetic conversions rank unsigned int above int, so a comparison between the two converts the signed operand to unsigned. A small negative value becomes an enormous positive one and the comparison quietly produces the wrong answer. Keep both operands signed unless you have a reason not to.

The Five Casts

Writing a cast is how you name the conversion you want instead of waiting to see which one the compiler picks. C++ gives you five, and they are nowhere near equally useful.

Cast What it is for Use it?
static_cast Converting a value of one type to another type Yes, this is the default
dynamic_cast Safe downcasting within polymorphic class hierarchies Later, once inheritance is on the table
const_cast Adding or removing const Avoid
reinterpret_cast Reinterpreting the bits as an unrelated type Avoid
C-style cast (int)x Whatever the compiler can make work Avoid

static_cast is by far the most used cast in C++. It is checked at compile time, it states the destination type plainly, and it is easy to search for. A C-style cast, by contrast, silently picks whichever of the others fits, so a harmless-looking (char*)p can turn into a reinterpret_cast without warning you.

#include <iostream>

int main()
{
    int litresCollected{ 745 };
    int daysMeasured{ 8 };

    std::cout << "both int:    " << litresCollected / daysMeasured << '\n';
    std::cout << "one cast:    " << static_cast<double>(litresCollected) / daysMeasured << '\n';

    return 0;
}

Output:

both int:    93
one cast:    93.125

Casting one operand is enough. Once the left operand is a double, the usual arithmetic conversions convert the right one to match, and the division is performed in floating point.

Aliases Rename, They Do Not Create

A type alias introduces a second name for an existing type, either with using NewName = Type; or with the older typedef Type NewName;. Both forms produce the same thing, and that thing is not a new type.

#include <iostream>

using Litres = double;
using Millimetres = double;

int main()
{
    Litres stored{ 430.0 };
    Millimetres depth{ 18.5 };

    depth = stored;        // compiles: both aliases name double
    double plain{ depth }; // compiles: so does the underlying type

    std::cout << "depth: " << depth << '\n';
    std::cout << "plain: " << plain << '\n';

    return 0;
}

Output:

depth: 430
plain: 430

Assigning a volume to a depth is nonsense, and the compiler allows it anyway, because Litres and Millimetres are both spellings of double.

Aliases carry no type safety
An alias improves readability and makes a widely used type easy to change in one place. It cannot stop you mixing up two values that happen to share an underlying type. Do not reason about aliased values as though the compiler were checking them for you.

What auto Keeps and What It Drops

With type deduction, which also travels under the name type inference, you leave the type off the declaration and let the initializer settle it. The rule that catches people out is that deduction strips const and strips references. If you want either, ask for it in the declaration.

You write Initializer type Deduced type
auto a{ ... } const int int
auto b{ ... } int& int
auto c{ ... } const int& int
const auto d{ ... } const int const int
const auto& e{ ... } const int const int& 
#include <iostream>

int main()
{
    const int capacityLitres{ 5000 };
    auto copied{ capacityLitres }; // deduced as int, the const is dropped
    copied = 4750;                 // so this is allowed

    int sensorLevel{ 12 };
    int& levelRef{ sensorLevel };
    auto plainCopy{ levelRef };    // deduced as int, not int&
    plainCopy = 99;                // sensorLevel is untouched

    const auto& keptRef{ capacityLitres }; // ask for const and reference explicitly

    std::cout << "copied: " << copied << '\n';
    std::cout << "sensorLevel: " << sensorLevel << '\n';
    std::cout << "plainCopy: " << plainCopy << '\n';
    std::cout << "keptRef: " << keptRef << '\n';

    return 0;
}

Output:

copied: 4750
sensorLevel: 12
plainCopy: 99
keptRef: 5000

auto also works as a function return type, where the compiler infers the return type from the return statements, and it is the required placeholder for trailing return syntax, in which the return type is written after the parameter list following a ->.

#include <iostream>

auto overflowLitres(double stored, double capacity) // return type deduced from the return statements
{
    if (stored > capacity)
        return stored - capacity;

    return 0.0;
}

auto litresPerDay(double total, int days) -> double // trailing return syntax
{
    return total / days;
}

int main()
{
    std::cout << "overflow: " << overflowLitres(5240.0, 5000.0) << '\n';
    std::cout << "per day:  " << litresPerDay(1188.0, 9) << '\n';

    return 0;
}

Output:

overflow: 240
per day:  132
Spell out return types on ordinary functions
Deduced return types force every caller to read the function body to learn what comes back, and they mean the function must be fully defined before it can be called. Write the type out. Deduction earns its keep in templates and lambdas, where the type is awkward or genuinely generic.

Key Terminology

  • Type conversion: producing a value of one type from a value of another type
  • Implicit type conversion: a conversion the compiler performs on its own when it meets a type mismatch
  • Automatic type conversion: another name for implicit type conversion
  • Coercion: another name for implicit type conversion
  • Standard conversions: the language's built-in catalogue of conversions between fundamental types
  • Numeric promotion: widening a narrower numeric type to int or double, the sizes the processor handles naturally
  • Integral promotion: the integral half of numeric promotion, targeting int, or unsigned int when int cannot hold every source value
  • Floating-point promotion: the floating-point half of numeric promotion, float to double
  • Value-preserving: describes a conversion in which no value or precision can be lost
  • Numeric conversion: any conversion between fundamental types that the promotion rules do not cover
  • Narrowing conversion: a numeric conversion that may lose value or precision
  • Usual arithmetic conversions: the ranked rules that give a binary operator two operands of matching type
  • Explicit type conversion: a conversion you request in the source with a cast
  • Cast: what you write to demand one particular conversion by name
  • C-style cast: the inherited (type)value form, which picks a conversion for you; avoid it
  • static_cast: the checked, readable, everyday cast, and the one you should reach for
  • const_cast: adds or removes const; avoid it
  • dynamic_cast: safe downcasting in polymorphic hierarchies, covered with inheritance
  • reinterpret_cast: low-level reinterpretation of a value's bits; avoid it
  • Type alias: a second name for an existing type, written using Name = Type;
  • Typedef: the older syntax for a type alias, written typedef Type Name;
  • auto: the placeholder that asks the compiler to deduce a type
  • Type deduction: working out a variable's type from its initializer
  • Type inference: another name for type deduction
  • Trailing return syntax: writing a function's return type after the parameter list with ->

Looking Forward

The habit worth carrying out of this chapter is reading a mixed-type expression the way the compiler does: identify the mismatch, name the conversion, and decide whether you want it. Most of the surprising bugs in this area are not exotic. They are an integer division that should have been floating point, a signed value compared against an unsigned one, or a double quietly truncated on the way into an int.

The same rules reappear as soon as your own types enter the picture. Classes can define their own conversions, function templates deduce parameter types using machinery closely related to auto, and the resolution rules grow extra steps to accommodate both. The vocabulary you have just built is what those later discussions assume you already have.