Override Correctness Pitfalls

Question

Problem: Override Correctness Pitfalls. Solve this hands-on electronics task on EWskills.

Accepted Answer

#include 
using namespace std;

class Driver {
public:
    virtual void process() {
        cout << "Generic driver processing" << endl;
    }
};

class SpiDriver : public Driver {
public:
    void process() override {
        cout << "SPI driver processing" << endl;
    }
};

class I2cDriver : public Driver {
public:
    void process() override {
        cout << "I2C driver processing" << endl;
    }
};

int main() {
    int mode;
    cin >> mode;

    SpiDriver spi;
    I2cDriver i2c;

    Driver* driver = nullptr;

    if (mode == 0) {
        driver = &spi;
    } else {
        driver = &i2c;
    }

    driver->process();

    return 0;
}

Explanation & Logic Summary:

The base class defines a virtual function process().

SPI driver case:
- The original version used a mismatched signature (const)
- Without override, the compiler allowed it
- The base implementation executed silently at runtime
I2C driver case:
- The override keyword was present
- The incorrect signature caused a compile-time error
- This prevented a silent runtime bug
The fix:
- Matches the exact base-class signature
- Adds override to both derived implementations
- Guarantees compile-time validation and correct polymorphism

Firmware Relevance & Real-World Context:

In real embedded firmware:

Drivers override callbacks such as IRQ handlers, DMA completion hooks, and state update functions
Silent override failures can cause hardware to remain unconfigured or unresponsive
Compile-time detection using override prevents field failures that are extremely difficult to debug

Core rule reinforced:

Every virtual function override must use override, and the compiler must be allowed to validate it.

This discipline is essential for building safe, reliable, and maintainable firmware systems.

152. Override Correctness Pitfalls