Enums, Casting and Type Conversions

Give meaningful names to a fixed set of choices, and understand exactly when C++ converts one type into another for you — and when you have to do it yourself.

10 min readUpdated 2026-09-03cppenumscastingtype-conversion

The problem enums solve

Imagine tracking a traffic light's color with an int:

cpp

int color = 0;   // 0 = red? 1 = green? Who remembers?

if (color == 1) { /* go */ }

Six months later, nobody — including you — remembers what 1 means. An enum replaces magic numbers with names:

cpp

enum class Color { Red, Green, Yellow };

Color light = Color::Green;

if (light == Color::Green) {
    std::cout << "Go\n";
}

Now the code reads like English, and the compiler catches a typo like Color::Gren immediately, instead of it silently becoming some unrelated integer.

`enum class` versus plain `enum`

C++ has two flavors, and modern code should almost always use the first one.

cpp

enum class Color { Red, Green, Yellow };   // scoped — modern, prefer this
enum OldColor { RED, GREEN, YELLOW };      // unscoped — legacy

The difference is what happens to the names outside the enum:

cpp

Color c = Color::Red;      // must qualify with Color::
OldColor o = RED;          // RED leaks directly into the surrounding scope

The unscoped version's names aren't namespaced, so if two enums both had a value called RED, they'd collide and refuse to compile in the same scope. enum class fixes this — each enum's values live inside their own name, exactly like Color:: here, the same way std:: scopes everything in the standard library.

What an enum actually is underneath

Each name in an enum secretly is an integer, starting at 0 and counting up, unless you say otherwise:

cpp

enum class Direction { North, East, South, West };
// North = 0, East = 1, South = 2, West = 3

enum class HttpStatus { OK = 200, NotFound = 404, ServerError = 500 };
// explicit values, useful when they need to match an external system

enum class values don't silently convert to int (that's the whole point of being "scoped" — it also blocks accidental mixing), but you can force it when you genuinely need the number:

cpp

Direction d = Direction::East;
int n = static_cast<int>(d);   // 1 — must be explicit

`switch` was made for enums

The control flow lesson covered switch. Enums are its best use case, because the compiler can warn you if you forget a case:

cpp

switch (light) {
    case Color::Red:    std::cout << "Stop\n"; break;
    case Color::Green:  std::cout << "Go\n"; break;
    case Color::Yellow: std::cout << "Slow down\n"; break;
}

Implicit conversions: when C++ converts for you

Beyond enums, C++ constantly converts between types automatically — sometimes helpfully, sometimes as a trap. The variables-and-types lesson already showed the two big ones (integer division, overflow). Here's the general rule: when types mix in an expression, the "smaller" one is promoted to the "larger" one before the operation happens.

cpp

int a = 5;
double b = 2.0;
double result = a / b;     // a is promoted to 5.0 first, then divided → 2.5

char c = 'A';
int code = c + 1;          // c promoted to int (65), result is 66

The promotion order, roughly smallest to largest: bool → char → int → long → long long → float → double. Mixing any two causes the smaller to become the larger — never the other way around, which is exactly why 5 / 2.0 gives you 2.5 instead of truncating like 5 / 2 does.

Narrowing: when a conversion loses data

The dangerous direction is going from a larger type to a smaller one — this is called narrowing, and the compiler will let you do it without complaint unless you use certain modern syntax.

cpp

double pi = 3.14159;
int whole = pi;          // 3 — the fractional part is just gone, no warning

int big = 300;
char small = big;        // undefined/implementation-defined — char often can't hold 300

Brace initialization specifically refuses to compile this silently:

cpp

int whole{pi};    // error: narrowing conversion, won't compile

This is one of the strongest reasons to prefer {} initialization over = for anything beyond the simplest cases — it turns a silent data-loss bug into a compile error you're forced to look at.

Explicit casts: telling the compiler "I meant to do this"

When you genuinely want a narrowing or type-changing conversion, say so explicitly with static_cast, rather than relying on an implicit one that looks accidental to anyone reading the code later.

cpp

double average = 7.0 / 2;               // 3.5
int rounded_down = static_cast<int>(average);  // 3, explicitly intentional

int total = 10, count = 3;
double avg = static_cast<double>(total) / count;  // 3.333..., not the trap from the types lesson

That last example is the fix for the classic integer-division bug from the variables-and-types lesson: casting one operand to double before the division forces the whole expression to promote to floating point. There are other cast forms (dynamic_cast, const_cast, reinterpret_cast) used in more advanced situations — static_cast is the one you'll reach for in ordinary code, and seeing (int)average-style old C casts in the wild is a sign of older code; prefer static_cast since it's checked more strictly by the compiler and is easier to search for in a large codebase.

Try it

Enums and casting togethercpp

Loading editor…

Common mistakes

Using plain enum instead of enum class in new code, risking name collisions.
Assuming int-to-char or double-to-int conversions warn you — they don't, unless you use brace initialization.
Old-style C casts (int)x instead of static_cast<int>(x) — both work, but static_cast is checked more strictly and easier to search for.
Forgetting to cast before division and hitting the integer-division trap again in a new disguise.
Comparing an enum class value directly to an int — it won't compile, which is a feature, not a bug; cast explicitly if you really need the number.

Summary

Enums replace magic numbers with names the compiler checks for you — always prefer enum class over plain enum in new code, since it avoids leaking names into the surrounding scope. C++ automatically promotes smaller types to larger ones in mixed expressions, but silently narrows larger types down to smaller ones, losing data without a warning unless you use brace initialization. Use static_cast whenever you want a conversion to happen and want that intent to be visible to anyone reading the code.

Contribute, invite only

Enums, Casting and Type Conversions

Give meaningful names to a fixed set of choices, and understand exactly when C++ converts one type into another for you — and when you have to do it yourself.

10 min readUpdated 2026-09-03cppenumscastingtype-conversion

The problem enums solve

Imagine tracking a traffic light's color with an int:

cpp

int color = 0;   // 0 = red? 1 = green? Who remembers?

if (color == 1) { /* go */ }

Six months later, nobody — including you — remembers what 1 means. An enum replaces magic numbers with names:

cpp

enum class Color { Red, Green, Yellow };

Color light = Color::Green;

if (light == Color::Green) {
    std::cout << "Go\n";
}

Now the code reads like English, and the compiler catches a typo like Color::Gren immediately, instead of it silently becoming some unrelated integer.

`enum class` versus plain `enum`

C++ has two flavors, and modern code should almost always use the first one.

cpp

enum class Color { Red, Green, Yellow };   // scoped — modern, prefer this
enum OldColor { RED, GREEN, YELLOW };      // unscoped — legacy

The difference is what happens to the names outside the enum:

cpp

Color c = Color::Red;      // must qualify with Color::
OldColor o = RED;          // RED leaks directly into the surrounding scope

What an enum actually is underneath

Each name in an enum secretly is an integer, starting at 0 and counting up, unless you say otherwise:

cpp

enum class Direction { North, East, South, West };
// North = 0, East = 1, South = 2, West = 3

enum class HttpStatus { OK = 200, NotFound = 404, ServerError = 500 };
// explicit values, useful when they need to match an external system

enum class values don't silently convert to int (that's the whole point of being "scoped" — it also blocks accidental mixing), but you can force it when you genuinely need the number:

cpp

Direction d = Direction::East;
int n = static_cast<int>(d);   // 1 — must be explicit

`switch` was made for enums

The control flow lesson covered switch. Enums are its best use case, because the compiler can warn you if you forget a case:

cpp

switch (light) {
    case Color::Red:    std::cout << "Stop\n"; break;
    case Color::Green:  std::cout << "Go\n"; break;
    case Color::Yellow: std::cout << "Slow down\n"; break;
}

Implicit conversions: when C++ converts for you

cpp

int a = 5;
double b = 2.0;
double result = a / b;     // a is promoted to 5.0 first, then divided → 2.5

char c = 'A';
int code = c + 1;          // c promoted to int (65), result is 66

Narrowing: when a conversion loses data

cpp

double pi = 3.14159;
int whole = pi;          // 3 — the fractional part is just gone, no warning

int big = 300;
char small = big;        // undefined/implementation-defined — char often can't hold 300

Brace initialization specifically refuses to compile this silently:

cpp

int whole{pi};    // error: narrowing conversion, won't compile

This is one of the strongest reasons to prefer {} initialization over = for anything beyond the simplest cases — it turns a silent data-loss bug into a compile error you're forced to look at.

Explicit casts: telling the compiler "I meant to do this"

When you genuinely want a narrowing or type-changing conversion, say so explicitly with static_cast, rather than relying on an implicit one that looks accidental to anyone reading the code later.

cpp

double average = 7.0 / 2;               // 3.5
int rounded_down = static_cast<int>(average);  // 3, explicitly intentional

int total = 10, count = 3;
double avg = static_cast<double>(total) / count;  // 3.333..., not the trap from the types lesson

Try it

Enums and casting togethercpp

Loading editor…

Common mistakes

Using plain enum instead of enum class in new code, risking name collisions.
Assuming int-to-char or double-to-int conversions warn you — they don't, unless you use brace initialization.
Old-style C casts (int)x instead of static_cast<int>(x) — both work, but static_cast is checked more strictly and easier to search for.
Forgetting to cast before division and hitting the integer-division trap again in a new disguise.
Comparing an enum class value directly to an int — it won't compile, which is a feature, not a bug; cast explicitly if you really need the number.