Implicit Conversions and Explicit Casts

Part I · Module 4 · Chapter 4.10 · Implicit Conversions and Explicit Casts

1. Conversions Happen Constantly

A conversion changes a value from one type to another. C++ performs them automatically in many places, and automatically means without you writing anything.

They happen when:

• two operands of an operator have different types (Chapter 4.2),
• a value is assigned to an object of a different type (Chapter 4.6),
• an object is initialized from a different type (Chapter 3.7),
• a value is passed to a function expecting a different type (Module 6),
• a value is returned from a function declared to return a different type (Module 6).

Most are harmless and most are what you wanted. The chapter is about the ones that are not, and about telling the difference.

2. Six Surprises, One Cause

Here is the thread, gathered. Every one of these has already appeared, measured, in this module or the last:

Six surprises that look unrelated. One cause: a conversion the programmer did not write.

That is the useful way to hold this. Not six rules, but one question to ask of any expression that behaves oddly:

Did a type change somewhere I did not write a type change?

3. The Conversions Worth Recognising

Four kinds account for nearly everything above.

Promotion. A type narrower than int becomes int. Always safe — every value survives. Chapter 4.2 §3.

Widening. A value moves to a type that can hold it: int to long, int to double. Normally safe, with one caveat below.

Narrowing. A value moves to a type that may not hold it: double to int, int to std::uint8_t. This is where data is lost, and Chapter 3.7 is the chapter about it.

Signed to unsigned. The value is converted modulo 2ᴺ (Chapter 3.3 §4), which turns negatives into large positives. The bits are frequently unchanged; the meaning is not.

4. Making a Conversion Visible

When you want a conversion, say so. The tool is static_cast:

    static_cast<double>(cycles)

Read it as: convert cycles to double, deliberately.

The canonical use is forcing the right arithmetic. Chapter 4.3 §1 showed integer division discarding the fraction and noted the conversion must be on an operand:

#include <iostream>

int main()
{
    int cycles    = 7;
    int transfers = 2;

    std::cout << "int / int   = " << cycles / transfers << '\n';
    std::cout << "with cast   = " << static_cast<double>(cycles) / transfers << '\n';

    double measured = 3.9;
    std::cout << "double->int = " << static_cast<int>(measured) << '\n';
    return 0;
}

Expected output:

int / int   = 3
with cast   = 3.5
double->int = 3

The cast on cycles makes it a double, so Chapter 4.2 §4's usual arithmetic conversions convert transfers as well and the division happens in floating point.

The third line shows the other direction: static_cast<int>(3.9) is 3. The fraction is discarded, exactly as the silent conversion would have — the difference is that a reader can see you meant it.

A cast does not make a conversion safe. It makes it visible, and makes you responsible for it.

5. Why Not the Inherited Form

C has one cast syntax, and C++ accepts it:

    (double)cycles        // C-style cast — do not use in C++

It is shorter. The problem is that it does not say which operation you asked for, and the operations available differ enormously.

Chapter 1.4 §7 demonstrated this and you now have the vocabulary to explain it:

#include <cstdint>
#include <cstring>
#include <iomanip>
#include <iostream>

int main()
{
    std::uint32_t bits = 0x3F800000u;      // the bit pattern of 1.0f

    float reinterpreted;
    std::memcpy(&reinterpreted, &bits, sizeof reinterpreted);   // reinterpret
    float converted = static_cast<float>(bits);                 // convert

    std::cout << std::fixed << std::setprecision(1);
    std::cout << "same bits, reinterpreted = " << reinterpreted << '\n';
    std::cout << "same value, converted    = " << converted << '\n';
    return 0;
}

Expected output:

same bits, reinterpreted = 1.0
same value, converted    = 1065353216.0

Two completely different results from one input. 0x3F800000 is the IEEE-754 pattern for 1.0f, so reading those bytes as a float gives 1.0. Converting the number 1,065,353,216 to float gives 1065353216.0.

Both are things an engineer sometimes wants. In C they are spelled the same way, so the source does not record which one the author meant — and a reader cannot tell a deliberate reinterpretation from an arithmetic conversion that went wrong.

static_cast will not do the reinterpretation at all:

error: static_cast from 'std::uint32_t *' (aka 'unsigned int *')
       to 'float *' is not allowed

That refusal is the feature. static_cast performs value conversions and related-pointer conversions; a bit-level reinterpretation requires a different, more conspicuous spelling.

There is a second, practical reason to avoid the C-style form: it is hard to search for. (int) appears in ordinary code constantly. static_cast<int> appears only where someone cast, which means a reviewer auditing conversions can find every one of them.

6. The Other Named Casts

C++ has three more. This chapter names them so you recognise them and does not teach them, because each needs machinery you have not met.

const_cast removes (or adds) const. Chapter 3.9 taught const on objects, and const_cast is almost always used with pointers and references, which are Module 8. It is also the one with the narrowest legitimate use: removing const to modify an object that was genuinely declared const is undefined behaviour.

reinterpret_cast reinterprets a bit pattern as a different type — the operation static_cast refused in §5. It is the tool for genuine type punning and for converting between pointers and integers, both of which belong to the hardware-facing work in Part II.

dynamic_cast asks at run time whether an object is of a particular derived type. That requires a class hierarchy, which arrives in Module 16. Chapter 17.8 teaches it.

For everything in Part I up to Module 8, static_cast is the one you want.

7. Where the Compiler Will and Will Not Warn You

Collecting what this module measured, because the pattern is the practical lesson:

The pattern: the compiler warns when it can see a specific value being damaged, and stays silent when the damage depends on a value it does not know.

That is the same compile-time/run-time split this module met three times — division by zero (4.3 §5), shift counts (4.8 §6), and signed overflow back in Chapter 3.3 §5. A check needs something to check at compile time.

Which is why the last row matters most. Chapter 3.7 §4's recommendation — brace initialization — is the only entry in that table that turns a silent conversion into a compile error, and it does so based on the types alone rather than on a value. That is why it works in exactly the case where warnings cannot help.

8. A Practical Policy

Four rules that cover nearly everything:

Prefer not converting. The best fix for most conversion problems is to choose the right type in the first place. Chapter 3.4's rule — when a width is part of a specification, say the width — removes whole categories of this.

Use braces to initialize. They reject narrowing conversions on the types, not on the values. Chapter 3.7 §8.

Cast explicitly when you mean it, with static_cast, and put it on the operand rather than the result. Chapter 4.2 §7 showed why: casting the result is too late, because the arithmetic already happened.

Keep -Wall -Wextra on, and treat a conversion warning as a question to answer rather than noise to clear.

9. Mistakes Worth Making Once

Assuming a clean build means no conversions happened. Measured: four of the six surprises in §2 produced no diagnostic at all.

Casting the result instead of an operand. static_cast<double>(cycles / transfers) divides as integers first, then converts 3 to 3.0.

Using a C-style cast. It does not say which operation you asked for, and the same syntax covers a value conversion and a bit reinterpretation that differ by a factor of a billion.

Believing a cast makes a conversion safe. It makes it visible. The data loss is identical; the responsibility moves to you.

Reaching for reinterpret_cast to silence an error. If static_cast refused, it refused for a reason. The usual correct fix is a different type, not a louder cast.

Converting a large integer to double and back. Beyond about 2⁵³ the round trip does not return the original.

Treating -Wsign-compare as noise. It is the one warning in §7's table that catches the signed/unsigned case, and Chapter 4.4 §3 showed what it is protecting you from.

10. Interview Relevance

This chapter carries the module's only Critical weighting, and the question behind it is a reliable discriminator.

"What is the difference between static_cast and a C-style cast?" is not asking you to list four cast names. It is checking whether you understand that a C-style cast performs one of several very different operations and does not record which, and that the named casts exist to make the dangerous ones conspicuous.

A strong answer gives the 1.0 versus 1065353216.0 example or something like it, notes that static_cast refuses the reinterpretation rather than silently performing it, and mentions searchability. A weaker answer lists the four casts without saying what problem they solve.

The companion question — "where does C++ convert implicitly?" — is really asking whether you have been bitten yet. §2's table is the answer.

11. What You Should Be Able to Say Now

1. Conversions happen at operators, assignment, initialization, argument passing and return — mostly without you writing anything.
2. Six surprises from this module had one cause: a conversion the programmer did not write.
3. The four kinds worth recognising: promotion (safe), widening (usually safe), narrowing (loses data), signed-to-unsigned (changes meaning).
4. Widening to floating point is not always lossless — beyond about 2⁵³ a 64-bit integer cannot be represented exactly in a double.
5. static_cast<T>(value) makes a conversion visible. It does not make it safe — it makes you responsible.
6. Measured: static_cast<double>(7) / 2 gives 3.5 where 7 / 2 gives 3; static_cast<int>(3.9) gives 3.
7. Put the cast on an operand, not the result.
8. A C-style cast does not say which operation you asked for. Measured: the same bits gave 1.0 reinterpreted and 1065353216.0 converted.
9. static_cast refuses the pointer reinterpretation, and that refusal is the feature.
10. Named casts are searchable; (int) is not.
11. const_cast, reinterpret_cast and dynamic_cast exist, are deliberately verbose, and belong to Modules 8, Part II and 17.8 respectively.
12. The compiler warns when it can see a specific value being damaged and is silent when it cannot — four of §2's six were silent.
13. Brace initialization is the only tool in the table that turns a silent narrowing into a compile error, because it works on types rather than values.

12. Exercises

Exercise 1 — name the conversion. For each, say which of §3's four kinds happens: (a) std::uint8_t to int in b + 1 (b) int to unsigned in i < u (c) double to int in int n = d; (d) int to long.

Exercise 2 — fix the average. int total = 7, count = 2; double avg = total / count; gives 3.0. Give the static_cast version, and say why static_cast<double>(total / count) would not work.

Exercise 3 — two casts, two answers. Given std::uint32_t bits = 0x40490FDBu, explain what a bit reinterpretation and a value conversion to float each produce, and which one an engineer decoding a floating-point register value wants.

Exercise 4 — predict the diagnostics. For each, say whether -Wall -Wextra -Wpedantic warns, errors, or is silent: (a) int n = 3.7; (b) int n = some_double; (c) int n{some_double}; (d) std::uint8_t c = 250; c += 10; (e) if (-1 < 4u).

Exercise 5 — why braces are different. Explain why brace initialization catches a narrowing conversion that a warning cannot, with reference to what each one has available at compile time.

Exercise 6 — audit a file. You are reviewing a file for unsafe conversions. Explain why static_cast and reinterpret_cast make this practical and a C-style cast does not, and say what you would search for.

Exercise 7 — one cause, six symptoms. Pick three rows from §2's table and explain, for each, exactly which conversion occurred and at which point in the expression. Then state the single question that would have caught all three.

13. Summary

• Conversions happen constantly — at operators, assignment, initialization, calls and returns — and mostly without being written.
• Six surprises across this module had one cause: a conversion nobody wrote.
• Four kinds: promotion (safe), widening (usually safe), narrowing (loses data), signed-to-unsigned (changes meaning).
• Widening into floating point is not always exact past about 2⁵³.
• static_cast makes a conversion visible, not safe, and belongs on an operand.
• A C-style cast hides which operation you meant — measured, 1.0 against 1065353216.0 from the same bits.
• static_cast refuses the reinterpretation, which is the point of having named casts.
• const_cast, reinterpret_cast and dynamic_cast are deliberately verbose and belong to later chapters.
• The compiler warns on visible values and is silent otherwise — four of six silent here.
• Brace initialization is the one tool that turns silent narrowing into an error, because it reasons about types.

Module 4 is finished. You can now read an expression the way the compiler does: what each operator produces, what type it produces, which conversions ran before it, how the operands grouped, and which parts of the order you may rely on. Together with Module 3's types, that is the complete vocabulary for a single line of C++.

What you still cannot do is write a program that makes a decision. Every example so far has run straight through from the first statement to the last, and the handful of if statements that appeared were borrowed without explanation because a condition needed somewhere to live. Module 5 gives them their proper treatment — the forms a decision can take, the loops that repeat work, and the small number of mistakes that account for most of the bugs beginners write in them.