Visual Studio - correcting different behaviour in an optimized build

I have a project I'm working on. I recently switched it to release mode with full optimization just to get an idea how some things will perform out of debug mode. On doing so however, I noticed that there were a few irregularities. In my particula开发者_如何学Cr case, I have a sprite who's alpha value is different (more transparent) in release mode then debug mode.

To check my findings, I made a copy of the release mode build options, but turned off optimizations (being sure that DEBUG and other related preprocessor options were removed) and it performed correctly. Something in the optimization process modifies the behaviour of my system. It's probably because there are variables I'm not initializing in my classes somewhere.

My question is, is there an alternative, aside from manually combing over my code, to making sure things are initialized properly? I've checked the warnings that pop up, but all are related to int to float/float to int conversion and possible loss of data and enum qualifiers, and none of them are related to the alpha on my sprite.

I'm using Visual Studio 2010 if it makes a difference.

This type of thing can be very difficult to debug. I suggest that you replace the optimization one-by-one, until you find the one that causes the anomly. You can then narrow the issue further by applying that optimization to each translation unit (file) one-by-one.

Another way to deal with this issue is essentially a data trace. Analyze code to determine what item of data is controling your alpha. Locate each statement that writes to the data. Put breakpoint or traces on those statements. Then determine the first point in the executable where the release data differs from the debug data.

Turn on as many warnings as you can to catch uninitialized variables. Run the code through a static LINT tool, like cppcheck. It's been a while since I've used VS, but I'm pretty sure you can set up your debugger to break on accessing uninitialized variable accesses and trace it from there.

If the code is multithreaded, then you likely have a race condition, or the compiler may be reordering things that wouldn't ordinarily make a difference if threads didn't interact, so if that's the case, double-check your proper use of locks.

Use an always-initialized template for all your member variables.

template<typename T> class always_initialized {
    T t;
public:
    operator T&() { return t; }
    operator const T&() const { return t; }
    always_initialized() : t(T()) {}
    template<typename K> always_initialized(K&& ref) : t(std::forward<K>(ref)) {}
};