auto and Type Deduction for Variables

Part I · Module 3 · Chapter 3.10 · auto and Type Deduction for Variables

1. Letting the Compiler Work It Out

    int  cycle_count = 19;      // you state the type
    auto cycle_count = 19;      // the compiler works it out

Both declarations create an object of type int holding 19. In the second, auto means deduce the type from the initializer.

The compiler looks at 19, sees that it is an int, and that is the type of the object. Nothing is left open.

Because the type comes from the initializer, an auto declaration must have one. auto x; gives the compiler nothing to work from and does not compile. That is a small consequence with a convenient side effect: auto makes the uninitialized declarations of Chapter 3.8 impossible to write.

2. What auto Is Not

This is the sentence to take away from the chapter:

auto does not make C++ dynamically typed. The type is determined once, while the program is being compiled, and the object has an ordinary static type for the rest of its life.

In a language that decides types at run time, a name can hold a number now and a piece of text later, and the program checks as it goes. C++ does not work that way and auto does not change it. The compiler performs the deduction, writes the type down, and from that point the object behaves exactly as if you had typed the name yourself.

auto is an instruction to the compiler about where to find the type, not a decision to stop having one.

3. Proving It

A short program settles the question:

int main()
{
    auto cycle_count = 19;      // deduced as int
    cycle_count = 3.9;          // allowed, but it is still an int
    return cycle_count;
}

The assignment compiles, with a warning:

autostatic.cpp:4:19: warning: implicit conversion from 'double' to 'int'
                     changes value from 3.9 to 3 [-Wliteral-conversion]

And the value stored is 3, not 3.9.

If auto meant dynamic typing, assigning a double would make the object a double and it would hold 3.9. It did not. The object was an int from the moment it was declared — deduced once, fixed thereafter — so the double was converted on the way in and the fractional part was lost.

That is the same narrowing conversion Chapter 3.7 §4 was about, which is worth noticing: auto does not protect you from it. The protection came from braces, and it is just as available here:

    auto cycle_count{19};       // still int, and narrowing on assignment is
                                // a separate question from initialization

You can confirm the deduced types directly:

#include <iostream>
#include <type_traits>

int main()
{
    auto cycle_count = 19;      // int
    auto ratio       = 0.5;     // double
    auto flag        = true;    // bool
    auto letter      = 'A';     // char
    auto wide_count  = 19u;     // unsigned int

    std::cout << "cycle_count is int?     " << std::is_same<decltype(cycle_count), int>::value << '\n';
    std::cout << "ratio is double?        " << std::is_same<decltype(ratio), double>::value << '\n';
    std::cout << "flag is bool?           " << std::is_same<decltype(flag), bool>::value << '\n';
    std::cout << "letter is char?         " << std::is_same<decltype(letter), char>::value << '\n';
    std::cout << "wide_count is unsigned? " << std::is_same<decltype(wide_count), unsigned int>::value << '\n';
    return 0;
}

Expected output:

cycle_count is int?     1
ratio is double?        1
flag is bool?           1
letter is char?         1
wide_count is unsigned? 1

All ones. std::is_same is a compile-time question about whether two types are the same — the same tool Chapter 3.6 §5 used on the character types — and decltype asks for the type of an expression. Both are answered while compiling, which is itself the point: these questions have answers at compile time because the types are fixed then.

Notice that the deduction follows the literal exactly. 19 is int, 19u is unsigned int, 0.5 is double, 'A' is char. The suffixes from Chapters 3.4 and 3.5 decide what you get.

4. One Deduction Rule Worth Knowing Now

auto deduction has rules that get genuinely involved once references and templates are in play. One of them matters immediately, because it surprises people:

auto drops top-level const.

#include <iostream>
#include <type_traits>

int main()
{
    const int setup_cycles = 3;
    auto copy = setup_cycles;          // deduced as int, NOT const int

    std::cout << "copy is const? " << std::is_const<decltype(copy)>::value << '\n';
    copy = 4;                          // legal: the copy is not const
    std::cout << "copy = " << copy << '\n';
    return 0;
}

Expected output:

copy is const? 0
copy = 4

setup_cycles is const int. copy is plain int, and assigning to it is fine.

The reasoning is sound once you see it: copy is a separate object holding its own value. The original's promise not to change says nothing about whether a copy may change. Chapter 3.1 §4 is what makes this readable — two objects, not one thing with two names.

If you want the copy to be const too, say so:

    const auto copy = setup_cycles;    // now const int

The same dropping happens with references, which you have not met yet. Module 8 covers references and what auto does with them, and Module 18 covers deduction in templates. The rule above is the one you need for this module.

5. Where auto Earns Its Place

Three situations where it genuinely improves code.

When the type is already obvious from the initializer. Writing it twice adds nothing:

    auto cycle_count = 19;          // plainly an int

When the type is long and the meaning is not in its name. You have not met types like this yet; they arrive with the standard library in Modules 19 and 20, where a type name can run to half a line and tell a reader nothing they did not already know from the line it came from. That is where auto goes from convenient to genuinely valuable.

When repeating the type would let it drift. If a function's return type changes and the call site named the old type explicitly, you get an unexpected conversion or an error. With auto the variable follows.

A fourth case, mentioned as orientation only because it is the one you will meet most: looping over the elements of a container, where the element type is already stated by the container. Chapter 5.6 showed the loop form and Module 20 puts it together properly.

6. Where auto Costs You

This section is the one most treatments skip, and for this curriculum's subject matter it is the more important half.

When the exact type is part of the engineering meaning. Compare:

    auto          status = read_register(0x4000'1004u);
    std::uint32_t status = read_register(0x4000'1004u);

The second says the value is exactly 32 bits and unsigned. Chapter 3.4 argued that for hardware data the width is part of what the value is, and the second line states it where a reader will see it. The first hides it in a function signature in another file.

That is the sharp case for this field: auto is weakest exactly where fixed-width types are strongest.

When the reader needs to know whether it is signed. Chapter 3.3 §7 showed a comparison returning the wrong answer because of a signedness mismatch. A reader checking for that problem needs to see the types. auto on both sides makes the review harder, not easier.

When the deduced type is not what the reader expects. Integer literals are int even when the context suggests something wider, and the deduction follows the literal rather than the intent:

    auto max_transfers = 4'000'000'000;   // what type is this?

That value does not fit in a 32-bit int. The compiler picks a type that can hold it, and which type that is depends on the platform. Stating the type you meant removes the question.

When auto hides a conversion. If the initializer's type differs from what you assumed, auto silently adopts the real one rather than converting to the one you had in mind — so a mismatch becomes invisible instead of becoming a diagnostic.

7. A Reasonable Default

Putting §5 and §6 together:

This is a judgement, not a rule, and that is deliberate. Advice of the form "always use auto" and "never use auto" are both easier to follow and both produce worse code than asking what the reader needs.

8. Mistakes Worth Making Once

Thinking auto makes C++ dynamically typed. The deduction happens at compile time and the type never changes. Measured: an int deduced from 19 stored 3 when assigned 3.9.

Expecting auto to protect against narrowing. It does not. Braces do — Chapter 3.7.

Expecting auto to preserve const. Top-level const is dropped, because the new object is a separate object. Write const auto if you want it.

Using auto for hardware values. The width and signedness are the engineering content, and auto moves them out of sight.

Using auto with a literal whose type you have not thought about. auto x = 4'000'000'000; has a platform-dependent answer.

Writing auto x;. There is no initializer to deduce from, so it does not compile — which incidentally makes Chapter 3.8's bug unwriteable.

Treating "always use auto" as a rule. It optimises for typing speed rather than for the person reading the code six months later.

9. What You Should Be Able to Say Now

1. auto asks the compiler to deduce the type from the initializer.
2. It is not dynamic typing. The deduction happens at compile time and the object has an ordinary static type afterwards.
3. Measured: auto cycle_count = 19; then cycle_count = 3.9; stores 3. The object was an int throughout.
4. An auto declaration must have an initializer, which makes Chapter 3.8's uninitialized declaration impossible to write.
5. Deduction follows the literal exactly: 19 is int, 19u is unsigned int, 0.5 is double, 'A' is char.
6. auto drops top-level const — measured, the copy was not const and could be assigned. Write const auto to keep it.
7. The reason is Chapter 3.1's model: the copy is a separate object, and the original's promise does not bind it.
8. auto does not protect against narrowing. Braces do.
9. Use auto when the type is obvious from the initializer, or long and uninformative.
10. Write the type when the width or signedness is part of the engineering meaning — which for hardware data it usually is.
11. The test: would a reader need the exact type to judge whether this line is correct?
12. "Always auto" and "never auto" are both worse than asking that question.

10. Exercises

Exercise 1 — predict the type. For each, state the deduced type: (a) auto a = 19; (b) auto b = 19u; (c) auto c = 1.8; (d) auto d = 1.8f; (e) auto e = 'A'; (f) auto f = true;.

Exercise 2 — the anti-dynamic proof. Explain what auto x = 19; x = 3.9; stores and why, and say what would have happened instead if auto were dynamic typing.

Exercise 3 — the dropped const. const int limit = 8; auto copy = limit; copy = 9; compiles. Explain why, using the object model from Chapter 3.1, and give the one-word change that would make the assignment an error.

Exercise 4 — judge four lines. For each, say whether auto or an explicit type is better and why: (a) auto i = 0; as a loop counter; (b) auto status = read_status_register();; (c) auto name = get_signal_name(); returning a long standard-library type; (d) auto length = packet.header_length(); where the field is specified as 16 bits.

Exercise 5 — the surprising literal. auto max_transfers = 4'000'000'000; — explain what makes this uncomfortable, and rewrite it so the type is unambiguous.

Exercise 6 — what auto does not fix. Give one problem from earlier in this module that auto does not protect you against, and name the feature that does.

Exercise 7 — apply the test. Take §6's test question and use it to argue both sides of one line: auto divider = measured_frequency / reference;. Say what a reader would need to know, and what you would write.

11. Summary

• auto deduces the type from the initializer, and therefore requires one.
• It is not dynamic typing. Deduction is a compile-time event; the object has a fixed static type afterwards.
• Measured: an auto-deduced int assigned 3.9 stored 3.
• Deduction follows the literal, suffixes included.
• Top-level const is dropped — the copy is a separate object. const auto keeps it.
• auto does not protect against narrowing; braces do.
• Use it when the type is obvious or long and uninformative.
• Write the type when width or signedness is part of the engineering meaning — which for hardware data it usually is.
• The test: would a reader need the exact type to judge correctness?
• Neither "always" nor "never" is a good rule.

Module 3 is finished. You can now say precisely what a declaration creates, choose a type on the basis of what the value actually is rather than habit, distinguish what C++ guarantees from what your platform happens to do, give an object its first value in a form that refuses to lose data quietly, and state immutability in a way the compiler enforces.

What you cannot yet do is much with those values. Every example in this module stored something and printed it; the few that computed anything did so without the rules being stated. Those rules are not obvious — Chapter 3.3 has already shown you a comparison between a signed and an unsigned value returning the opposite of what it should, and the explanation was deferred both times it came up. Module 4 is where expressions get their proper treatment: what an operator does with its operands, what type the result has, which conversions happen before any operator runs, and why the answer to all three is more interesting than arithmetic has any right to be.