Senior 6 min · March 06, 2026

C++ Type Casting Gotcha — static_cast Downcast Corruption

Intermittent data corruption in order processing due to static_cast downcast on wrong derived type.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
Quick Answer
  • C++ offers four named casts: static_cast, dynamic_cast, reinterpret_cast, and const_cast — each with a specific purpose and safety profile.
  • static_cast is compile-time checked, zero overhead, for numeric conversions and known type hierarchy navigations.
  • dynamic_cast is the only runtime-checked cast, using RTTI to verify type — safe but costs a vtable lookup.
  • reinterpret_cast reinterprets raw bits; no conversion, no safety — use only for hardware or void* interop.
  • const_cast adds or removes cv-qualifiers; writing to an originally const object is UB.
  • Performance: dynamic_cast adds ~50-100ns per call; avoid in hot loops; static_cast is free.
  • Production insight: Using static_cast to downcast an object not of the derived type causes silent UB — always use dynamic_cast when uncertainty exists.
Plain-English First

Imagine you have a jar of coins and you want to pour them into a piggy bank with a narrower slot. You might need to sort them first — some fit fine, some need to be reshaped, and forcing the wrong coin through could break the slot. Type casting is exactly that: telling C++ 'I know this value is stored as one type, but treat it as this other type instead.' Sometimes it's perfectly safe, sometimes it's a controlled risk, and sometimes it's genuinely dangerous — and C++ gives you four distinct tools so you always know which situation you're in.

Every real C++ program eventually hits a moment where two types need to talk to each other. A sensor returns a raw byte array, but you need floating-point temperatures. A base-class pointer holds a derived object, and you need to call a derived-only method. A legacy C library hands you a void* and expects you to know what lives inside it. These aren't edge cases — they're Tuesday. Type casting is how C++ lets you cross those boundaries deliberately and, when you use the right cast, safely.

The problem C++ was solving when it introduced four named casts (static_cast, dynamic_cast, reinterpret_cast, and const_cast) was that the old C-style cast — writing (int)someValue — is a blunt instrument. It silently does whatever it takes to make the conversion happen, masking bugs that can take days to track down. The named casts force you to be explicit about your intent, which means the compiler can reject nonsensical conversions and reviewers can grep for dangerous ones in seconds.

By the end of this article you'll know exactly which cast to reach for in any situation, why the C-style cast is a code smell in modern C++, how to safely navigate class hierarchies with dynamic_cast, and the two runtime pitfalls that catch even experienced developers off guard. You'll also have a comparison table you can bookmark and interview answers ready to go.

Implicit vs Explicit Casting — What C++ Does Without Being Asked

Before you ever write the word 'cast', C++ is already casting things for you. Assign an int to a double and the compiler quietly widens the value. Pass a short to a function expecting a long and it just works. These are implicit conversions — the compiler considers them safe because no information is lost.

But the moment information might be lost — like assigning a double to an int, chopping off the decimal — the compiler starts warning you. That's the boundary between implicit and explicit casting. Explicit casting is you telling the compiler: 'Yes, I know what I'm doing. Do it anyway.'

Understanding this boundary is critical because it shapes which named cast you'll use. Safe, well-defined conversions belong to static_cast. Dangerous, low-level reinterpretations belong to reinterpret_cast. Modifying const-ness belongs to const_cast. And navigating polymorphic class hierarchies belongs to dynamic_cast. Each tool has a specific lane — and straying into the wrong one is where bugs are born.

ImplicitVsExplicit.cppCPP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/* 
 * io.thecodeforge.casting: Implicit vs Explicit Demo
 */
#include <iostream>

int main() {
    // --- IMPLICIT CONVERSION (compiler handles this silently) ---
    int sensorRawReading = 42;
    double calibratedTemperature = sensorRawReading; // int -> double: safe
    std::cout << "Calibrated temperature: " << calibratedTemperature << "\n";

    // --- IMPLICIT NARROWING (POTENTIAL DATA LOSS) ---
    double preciseVoltage = 3.987;
    int roundedVoltage = preciseVoltage; // Truncates .987 silently
    std::cout << "Rounded voltage (implicit): " << roundedVoltage << "\n";

    // --- EXPLICIT CAST (THE CODEFORGE WAY) ---
    // static_cast makes the truncation visible and intentional
    int intentionallyTruncated = static_cast<int>(preciseVoltage);
    std::cout << "Intentionally truncated: " << intentionallyTruncated << "\n";

    return 0;
}
Output
Calibrated temperature: 42
Rounded voltage (implicit): 3
Intentionally truncated: 3
Forge Tip:
Enable -Wconversion in GCC/Clang or /W4 in MSVC. These flags surface implicit narrowing conversions that compile silently but corrupt data at runtime. Treat every warning they emit as a candidate for an explicit static_cast with a comment explaining why the truncation is intentional.
Production Insight
Implicit narrowing conversions are a ticking time bomb.
A sensor reading truncated from double to int cost $500k in a medical device recall.
Rule: enable -Wconversion and treat each warning as a static_cast candidate.
Key Takeaway
Implicit conversions are safe only when no data is lost.
Any narrowing should be explicit via static_cast.
Every truncation must be visible in code review.

static_cast — Your Everyday Workhorse for Safe, Compile-Time Conversions

static_cast is the cast you'll use 90% of the time. It handles conversions that are well-defined by the C++ standard and checked entirely at compile time — meaning there's zero runtime overhead. If the conversion doesn't make sense (casting a string to a pointer-to-int, for example), the compiler refuses to compile it. That's the key promise: static_cast fails loudly at compile time rather than silently at runtime.

The most common uses fall into three buckets. First, numeric conversions: double to int, int to float, long to short. Second, navigating class hierarchies when you already know the actual type — called a downcast without a safety net. Third, explicitly resolving ambiguous arithmetic, like forcing integer division to behave as floating-point division by casting one operand first.

Because static_cast is checked at compile time, it cannot protect you if your assumption about the actual runtime type is wrong. That's not a flaw — it's by design. static_cast is a promise you make to the compiler. If that promise involves runtime polymorphism, use dynamic_cast instead.

StaticCastExamples.cppCPP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#include <iostream>

namespace io::thecodeforge {
    class Vehicle {
    public:
        virtual ~Vehicle() = default;
        void describe() const { std::cout << "I am a vehicle\n"; }
    };

    class ElectricCar : public Vehicle {
    public:
        void chargeBattery() const { std::cout << "Charging battery...\n"; }
    };
}

int main() {
    using namespace io::thecodeforge;

    // USE CASE 1: Fixing integer division
    int totalDistance = 350; 
    int numberOfTrips = 4;
    double correctAverage = static_cast<double>(totalDistance) / numberOfTrips;
    std::cout << "Average: " << correctAverage << " km\n";

    // USE CASE 2: Safe Upcast (Derived -> Base)
    ElectricCar myTesla;
    Vehicle* vPtr = static_cast<Vehicle*>(&myTesla); 
    vPtr->describe();

    // USE CASE 3: Downcast (Only if type is GUARANTEED)
    ElectricCar* carPtr = static_cast<ElectricCar*>(vPtr);
    carPtr->chargeBattery();

    return 0;
}
Output
Average: 87.5 km
I am a vehicle
Charging battery...
Watch Out:
static_cast for downcasts (Base to Derived) is undefined behaviour if the object isn't actually of the derived type at runtime. The code compiles cleanly and may even run without crashing — right up until it silently corrupts memory. If there's any doubt about the actual runtime type, always use dynamic_cast instead.
Production Insight
Using static_cast on an uncertain pointer is the #1 cause of silent data corruption in polymorphic code.
A trading system once wrote wrong prices for 20 minutes before detection.
Rule: if you can't prove the type at compile time, use dynamic_cast.
Key Takeaway
static_cast is for when you know the types perfectly.
It's zero cost but zero safety net.
When in doubt about runtime type, dynamic_cast is the only safe path.

dynamic_cast — The Safe Downcast with a Runtime Safety Net

dynamic_cast is the only C++ cast that does real work at runtime. It inspects the object's actual type information (stored in the vtable) and returns nullptr for pointers, or throws std::bad_cast for references, if the conversion isn't valid. That safety net costs a small runtime fee — a vtable lookup — but it's worth every nanosecond when correctness matters more than microseconds.

For dynamic_cast to work, the class hierarchy must be polymorphic — the base class needs at least one virtual function. That's not an arbitrary restriction; it's because virtual functions are what give C++ objects runtime type information (RTTI) in the first place. A class with no virtual functions has no RTTI, and dynamic_cast has nothing to inspect.

The canonical use case is a system where you receive a base class pointer from somewhere (a factory, a container, a callback) and need to call a method that only exists on one specific derived type. dynamic_cast lets you ask 'is this actually a Derived?' at runtime, handle the null case gracefully, and move on — no undefined behaviour, no crashes.

DynamicCastSafety.cppCPP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#include <iostream>
#include <vector>
#include <memory>

namespace io::thecodeforge {
    class Shape {
    public:
        virtual ~Shape() = default; // Essential for RTTI
        virtual void draw() const = 0;
    };

    class Circle : public Shape {
    public:
        void draw() const override { std::cout << "Drawing Circle\n"; }
        void specialCircleMethod() const { std::cout << "Performing radius-specific logic\n"; }
    };

    class Square : public Shape {
    public:
        void draw() const override { std::cout << "Drawing Square\n"; }
    };
}

void processShape(const io::thecodeforge::Shape* s) {
    using namespace io::thecodeforge;
    if (s == nullptr) return;

    // Runtime check: is 's' actually a Circle?
    if (const Circle* c = dynamic_cast<const Circle*>(s)) {
        c->specialCircleMethod();
    } else {
        std::cout << "Not a circle, skipping special logic.\n";
    }
}

int main() {
    using namespace io::thecodeforge;
    
    std::unique_ptr<Shape> s1 = std::make_unique<Circle>();
    std::unique_ptr<Shape> s2 = std::make_unique<Square>();

    processShape(s1.get());
    processShape(s2.get());
    
    return 0;
}
Output
Performing radius-specific logic
Not a circle, skipping special logic.
Interview Gold:
Interviewers love asking 'when would you prefer dynamic_cast over static_cast for a downcast?' The answer: whenever you don't have a compile-time guarantee of the actual derived type. If a factory or external system gives you a Base*, and the concrete type depends on runtime input, dynamic_cast is the only safe option. static_cast on an uncertain pointer is undefined behaviour waiting for a demo to go wrong.
Production Insight
dynamic_cast overhead is real but often overstated.
In a game loop running at 60fps, a few hundred dynamic_casts per frame are fine.
The cost is not the number of casts but the number of times you cast the same object — cache the result.
Rule: use dynamic_cast once and store the derived pointer if you need it repeatedly.
Key Takeaway
dynamic_cast is your insurance policy against undefined behaviour.
It costs a vtable lookup but saves you from silent corruption.
Prefers pointer form and check for nullptr over reference and exception.

reinterpret_cast and const_cast — Power Tools You Rarely Need and Must Respect

reinterpret_cast is C++'s most dangerous cast. It doesn't convert data — it reinterprets the raw bits at an address as a completely different type. No conversion happens, no safety checks, no guarantees. The compiler simply agrees to look at the same memory through a different lens. This is occasionally necessary when working with hardware registers, network packet buffers, or legacy C APIs that traffic in void*.

const_cast has one job: add or remove const from a variable. Its legitimate use case is narrow but real — calling a legacy C function that takes a non-const char when you have a const char and you know for certain the function won't modify the data. Using const_cast to write to something that was originally declared const is undefined behaviour, full stop.

Both casts are grep-friendly by design. In a code review, you can search for reinterpret_cast and const_cast and immediately have a list of every place the codebase does something unusual. That's the entire point of having named casts instead of a single C-style catch-all.

PowerCastsDemo.cppCPP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
/* 
 * io.thecodeforge: Low-level reinterpretation and Const bridging
 */
#include <iostream>
#include <cstdint>

void legacyPrint(char* str) { std::cout << "Legacy C Output: " << str << "\n"; }

int main() {
    // 1. reinterpret_cast: Looking at float bits as an integer
    float val = 3.14f;
    // Note: In production, std::bit_cast (C++20) is safer/better than this
    uint32_t bits = *reinterpret_cast<uint32_t*>(&val);
    std::cout << std::hex << "Raw Float Bits: 0x" << bits << std::dec << "\n";

    // 2. const_cast: Bridging to non-const legacy C API
    const char* message = "Forge Safety Check";
    // We know legacyPrint won't mutate 'message'
    legacyPrint(const_cast<char*>(message));

    return 0;
}
Output
Raw Float Bits: 0x4048f5c3
Legacy C Output: Forge Safety Check
Watch Out:
reinterpret_cast between unrelated pointer types violates C++'s strict aliasing rules unless the types involved are char, unsigned char, or std::byte. Reading a float's bits via a uint32_t pointer (as shown above) is actually implementation-defined, not fully portable. The truly portable way is std::memcpy into a uint32_t variable. Use reinterpret_cast only when you understand the aliasing implications on your target platform.
Production Insight
reinterpret_cast is often the wrong tool even when it seems right.
Using it for type punning can cause the compiler to optimise away loads due to strict aliasing.
A network packet parser once returned wrong values because the compiler reordered reads across a reinterpret_cast.
Rule: prefer std::bit_cast (C++20) or memcpy for type punning.
Key Takeaway
reinterpret_cast and const_cast are the last resort.
Both violate type safety — use them only when no alternative exists.
Always comment exactly why the cast is safe and what invariant protects it.

C-Style Cast: The Blunt Instrument You Should Never Use in Modern C++

Before C++ introduced named casts, developers wrote (Type)value — the C-style cast. It's still valid today, but it's a code smell. The problem? The C-style cast silently tries a combination of static_cast, const_cast, and reinterpret_cast, whichever works. It can strip away const without warning, or reinterpret memory without your knowledge.

Here's what happens when you write (int)someValue: the compiler attempts static_cast first; if that fails, it tries reinterpret_cast; if that fails, it tries const_cast. You get no indication of which one actually applied. This makes C-style casts dangerous in code review because the reader can't tell if the operation is safe (static_cast) or dangerous (reinterpret_cast) just by looking at it.

Modern C++ projects ban C-style casts entirely, or at least restrict them to trivial numeric conversions where the intent is obvious. Tools like clang-tidy enforce this via the cppcoreguidelines-pro-type-cstyle-cast rule. At TheCodeForge, we treat every C-style cast as a bug until proven otherwise.

CStyleCastDangers.cppCPP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <iostream>

int main() {
    const int x = 42;
    // C-style cast: strips const silently
    int* p = (int*)&x; 
    *p = 100; // UB: writing to originally const memory
    std::cout << "x = " << x << " (value may be optimized to 42)\n";

    // Better: use const_cast explicitly to signal intent
    int* p2 = const_cast<int*>(&x); // Still UB if you write, but at least visible
    // *p2 = 200; // Avoid!
    
    return 0;
}
Output
x = 42 (value may be optimized to 42)
Linter Rule:
Enable clang-tidy's cppcoreguidelines-pro-type-cstyle-cast and google-readability-casting. These will flag every C-style cast as a warning or error. In a production codebase, we configure them as errors in CI so no C-style cast can pass code review.
Production Insight
A C-style cast that strips const caused a financial system to miscalculate interest for two weeks.
The object was declared const, the compiler cached its value, and writes through the cast had no effect.
Rule: ban C-style casts with a linter — every cast must be a named cast with explicit intention.
Key Takeaway
C-style cast is a silent multithreat.
It can hide const-correctness violations and unsafe reinterpretations.
Use named casts only; they make every type conversion grep-able and reviewable.

Choosing the Right Cast: A Decision Framework

With four named casts and one to avoid, choosing the right one on the spot can feel overwhelming. Here's a simple decision tree you can apply every time you need to convert a type.

Ask yourself: Is the conversion numeric? If yes, use static_cast. Is the conversion between pointer types in a class hierarchy? If you know the exact derived type at compile time (e.g., you just created it), use static_cast. If the type is determined at runtime (e.g., from a factory or container), use dynamic_cast. Is the conversion about reinterpreting raw memory? Use reinterpret_cast only when you know strict aliasing rules and alignment. Is the conversion about adding or removing const? Use const_cast, but only for calling legacy APIs that take non-const parameters but don't modify.

For every cast, ask: 'Is there a way to avoid this cast?' Often, better design — templates, virtual functions, or std::variant — eliminates the need for casting entirely. But when casting is necessary, the named casts give you the precision and safety you need.

DecisionFramework.cppCPP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <type_traits>
#include <iostream>

// io.thecodeforge: Decision framework for casts

template <typename To, typename From>
constexpr bool is_safe_numeric_cast() {
    return std::is_arithmetic_v<From> && std::is_arithmetic_v<To>;
}

int main() {
    // Numeric conversion -> static_cast
    double d = 3.14;
    int i = static_cast<int>(d);
    
    // Known downcast -> static_cast (only when you know the type!)
    // dynamic_cast -> when uncertain
    
    // Raw memory -> reinterpret_cast (but prefer std::bit_cast)
    uint64_t raw = 0;
    double* dp = reinterpret_cast<double*>(&raw); // dangerous
    
    // Const removal -> const_cast (only for legacy non-modifying APIs)
    const char* msg = "hello";
    char* mutable_msg = const_cast<char*>(msg);
    
    return 0;
}
Output
(No output – decision framework illustration)
Mental Model: The Cast Decision Ladder
  • static_cast: base of the ladder — safe, compile-time, zero cost.
  • dynamic_cast: the safety harness — runtime check, small cost.
  • const_cast: a special tool — only for const-correctness bridging.
  • reinterpret_cast: the top rung — dangerous, last resort, raw bits.
  • C-style cast: not on the ladder — it's a slippery slope.
Production Insight
Overusing casts points to a design smell.
If you need a downcast, ask if the base class interface is complete.
If you need reinterpret_cast, consider if the data layout can be redesigned.
Rule: every cast in your codebase should have a comment explaining why it's needed and why it's safe.
Key Takeaway
Choose casts deliberately: static_cast for safe, dynamic_cast for safe downcast, const_cast for legacy bridges, reinterpret_cast as last resort.
The C-style cast has no place in modern C++.
Fewer casts mean better design.
Which Cast to Use?
IfNumeric conversion (e.g., int to double)
UseUse static_cast.
IfUpcast in a class hierarchy (Derived to Base)
UseUse static_cast (implicit upcast also works).
IfDowncast (Base to Derived) with guaranteed type
UseUse static_cast (only if you hold the compile-time guarantee).
IfDowncast with runtime-dependent type
UseUse dynamic_cast and check for nullptr.
IfReinterpret raw bits (hardware, packet buffers)
UseUse reinterpret_cast but verify alignment and aliasing.
IfRemove const to call a legacy C API
UseUse const_cast only if the API does not modify the data.
● Production incidentPOST-MORTEMseverity: high

The Phantom Derived: A static_cast Downcast That Corrupted Production Data

Symptom
Intermittent data corruption in order processing — some orders had wrong customer ID, but only for certain product categories.
Assumption
All objects passed through the pipeline were of type 'PremiumOrder' because the business logic always created PremiumOrders for those categories.
Root cause
A legacy code path could produce a 'StandardOrder' object under edge conditions. The code used static_cast<PremiumOrder*>(basePtr) to call a method only on PremiumOrder, leading to reading memory at wrong offsets.
Fix
Replace static_cast with dynamic_cast<PremiumOrder*> and check for nullptr before using the pointer. Also add a virtual destructor to the base class to enable RTTI.
Key lesson
  • Never assume runtime type based on business logic alone.
  • Use dynamic_cast when the type is not guaranteed at compile time.
  • Always test with all possible derived types in integration tests.
Production debug guideSymptom → Action guide for the four named casts4 entries
Symptom · 01
dynamic_cast returns nullptr unexpectedly
Fix
Check if base class has at least one virtual function (RTTI requirement). Also ensure object is actually of the target type.
Symptom · 02
reinterpret_cast causes crash or wrong values
Fix
Verify alignment and strict aliasing rules. Consider using std::bit_cast or memcpy instead.
Symptom · 03
const_cast write causes seemingly random corruption
Fix
Check if the original object was declared const. If yes, redesign to avoid const_cast. If no, ensure the cast is needed only for legacy APIs that don't modify.
Symptom · 04
static_cast downcast works in debug but corrupts in release
Fix
Enable RTTI and use dynamic_cast instead, or add a type tag enum.
★ Quick Debug Cheat Sheet: Casting ErrorsImmediate steps when a cast behaves wrong in production
static_cast downcast returns garbage data
Immediate action
Stop the process to prevent corruption. Identify the pointer's actual type.
Commands
Use dynamic_cast with nullptr check in a debug build to see if it fails.
Add logging to print typeid(*ptr).name() before the cast.
Fix now
Replace static_cast<Derived>(ptr) with dynamic_cast<Derived>(ptr) and handle nullptr.
const_cast write causes variable to not update+
Immediate action
Check if the original variable was declared const.
Commands
Search for all const_cast occurrences in the codebase.
Use static analysis tools to flag potentially dangerous const_cast.
Fix now
If the variable was originally const, remove const_cast and redesign. If not, ensure the casted variable is the only reference.
dynamic_cast throws std::bad_cast+
Immediate action
Wrap the cast in a try-catch block to prevent crash.
Commands
Check reference type: if using dynamic_cast on a reference, failure throws instead of returning null.
Add a typeid check before the cast where possible.
Fix now
Convert to a pointer-based dynamic_cast and check for nullptr before use.
Cast TypeChecked AtFails HowUse CaseRuntime CostSafety Level
static_castCompile timeCompile errorNumeric conversions, known downcasts, upcastsNoneHigh (if types are correct)
dynamic_castRuntimenullptr or std::bad_castPolymorphic downcasts, type-safe RTTI queriesvtable lookupHighest (runtime verified)
reinterpret_castNeitherSilent UB or crashRaw memory, hardware registers, void* interopNoneLowest — you own the risk
const_castCompile timeCompile error (wrong use: UB)Removing const for legacy C API calls onlyNoneMedium — UB if original was const
C-style cast (int)xCompile timeOften silentNever in modern C++NoneLowest — tries four cast types silently

Key takeaways

1
static_cast is your default
it's compile-time checked, zero-cost, and covers numeric conversions and upcasts. Use it explicitly instead of relying on implicit narrowing so your intent is visible to reviewers.
2
dynamic_cast is the only cast that asks the object itself what type it is at runtime
this costs a vtable lookup but is the only safe way to downcast when the concrete type isn't guaranteed at compile time.
3
reinterpret_cast and const_cast are specialised tools for interop with hardware or legacy C APIs
their presence in a codebase should always be accompanied by a comment explaining the exact invariant that makes them safe.
4
The C-style cast (Type)value silently tries static_cast, then reinterpret_cast, then const_cast in sequence
it can therefore strip const or reinterpret memory without any visual warning. Treat it as a code smell and ban it in modern C++ projects via linter rules.
5
Fewer casts mean better design. If you find yourself using dynamic_cast or reinterpret_cast frequently, reconsider your type hierarchy or data layout. Virtual functions and templates often eliminate the need for casting.

Common mistakes to avoid

4 patterns
×

Using static_cast for uncertain polymorphic downcasts

Symptom
The code compiles and may run fine in testing, then silently corrupts memory or calls the wrong virtual function in production when the actual object type differs from the assumption.
Fix
Any time the runtime type is not guaranteed at compile time, replace static_cast<Derived>(basePtr) with dynamic_cast<Derived>(basePtr) and check the result for nullptr before use.
×

Forgetting that dynamic_cast requires a polymorphic base class

Symptom
The compiler gives a cryptic error like 'source type is not polymorphic' and beginners don't know why.
Fix
Add at least one virtual function to the base class — in practice, always add a virtual destructor (virtual ~Base() = default;). This is also best practice to prevent partial destruction of derived objects.
×

Using const_cast to write through a pointer to a const-declared variable

Symptom
This compiles without error, appears to work in debug builds, then breaks in release builds because the compiler has cached the const variable's value in a register or inlined it as a literal.
Fix
Never use const_cast to modify originally-const data. If you need a mutable version, redesign so the variable isn't const, or use mutable member variables for logically-const classes.
×

Using reinterpret_cast for type punning without considering strict aliasing

Symptom
Code produces different results with different optimisation levels, or crashes when the compiler reorders accesses.
Fix
Use std::bit_cast (C++20) or std::memcpy for type punning. Only use reinterpret_cast when working with char, unsigned char, or std::byte* which are exempt from strict aliasing.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
Explain the 'Strict Aliasing Rule' and how it impacts the safety of rein...
Q02SENIOR
Why does dynamic_cast return nullptr for pointers but throw an exception...
Q03SENIOR
How does the compiler implement dynamic_cast internally? Discuss the rol...
Q04SENIOR
In a high-frequency trading system, why might you prefer static_cast ove...
Q05SENIOR
Can you use dynamic_cast to perform a 'side-cast' in a multiple inherita...
Q01 of 05SENIOR

Explain the 'Strict Aliasing Rule' and how it impacts the safety of reinterpret_cast in performance-critical code.

ANSWER
The strict aliasing rule says you can only access an object through a pointer/reference to its own type or a compatible type (char, unsigned char, std::byte). Using reinterpret_cast to read a float as a uint32_t is a violation because the types are unrelated. The compiler may assume the pointers don't alias and optimise away loads, leading to incorrect values. The safe alternative is std::bit_cast or memcpy, which the compiler optimises to the same assembly but respects aliasing rules.
FAQ · 7 QUESTIONS

Frequently Asked Questions

01
What is the difference between C-style cast and static_cast in C++?
02
Does dynamic_cast have a performance overhead?
03
Why does dynamic_cast return nullptr?
04
What is the difference between static_cast and reinterpret_cast?
05
Is it safe to use static_cast for downcasting?
06
Can I use reinterpret_cast to cast between unrelated pointer types?
07
What's the best way to avoid dynamic_cast in performance-critical code?
🔥

That's C++ Basics. Mark it forged?

6 min read · try the examples if you haven't

Previous
File I/O in C++
13 / 19 · C++ Basics
Next
Lambda Expressions in C++