The Risk of Micro-optimizations

A lot of things have been said over the years about premature optimization, and after running into the following bug I thought it served as a good example of a type of premature optimization that I call "micro-optimization". That is, doing something quirky in order to save a tiny amount of RAM or CPU cycles. More often than not these quirks lead to bugs and less maintainable code, with no actual performance increase.

The following bug was in a class in an application designed to run on a modern desktop, and there would only be a few instances alive at any one time (say, 1-10 typically, maybe 100 in edge cases), so the amount of memory saved was negligible (if any).

This is a rather easy "spot the bug" exercise so I won't give it away. ;-)

 DWORD WEATHER_SUNNY   = 0x0001;
DWORD WEATHER_RAINING = 0x0002;

struct CWeather
{
    BOOL _fRaining:1;

    CWeather(DWORD dwFlags)
    {
        _fRaining = (dwFlags & WEATHER_RAINING);
    }

    BOOL IsRaining()
    {
        return _fRaining;
    }
};

int main()
{
    CWeather weather(WEATHER_RAINING);

    if (weather.IsRaining())
    {
        cout << "It's raining!" << endl;
    }
    else
    {
        cout << "It's not raining!" << endl;
    }

    return 0;
}

Note: Depending on your compiler, if you crank up your warning level high enough you should get a warning for this. (Although curiously I didn't with VS 2005 and /W4).