Home/ Questions/Q 6708229
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T07:44:02+00:00

I’ve got a C++ project in Visual Studio 2010. I’m simply trying to compare

  • 0

I’ve got a C++ project in Visual Studio 2010.

I’m simply trying to compare two strings to one another but I’m seeing wildly different behavior in my Release build. The Debug build works as expected. I haven’t made any changes to optimizations other than the default values that Visual Studio 2010 sets.

Here’s my code:

wchar_t validCRC[] = L"0xd07153b9";
wchar_t thisCRC[] = L"0xd07153b9"; // this is calculated on the fly but I get same behavior if I set it manually. i also tried setting these both to L"hello" and got same result

int cmp = 0;
cmp = wcscmp(validCRC, thisCRC); // if I put a breakpoint here, the visual studio debugger says 'cmp' is not in scope. 
pLog->Write("value of cmp: %d", cmp); // in both DEBUG and RELEASE, this prints "value of cmp: 0"

if (cmp == 0)
{ // yet for some reason, the DEBUG build follows this path
    return true;
}
else
{ // the RELEASE build follows this path
    return false;
}
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Release builds are optimized, so it’s often hard for the debugger to give you values of individual variables, especially local variables which are often stored registers that are used for something else a few instructions later.

    That’s why you use a debug build for debugging, and the release build for the build that you will release.

    If you really need to debug a problem that only occurs in a release build (uninitialized variables are very commonly the reason there), you could use a compiler-specific #pragma to only de-optimize certain parts, or you could de-optimize certain files, or you could make use of printf instructions.

    EDIT: When you say “follow” this path, you probably mean that’s what it looks like when you step through it in the debugger. Again, the code is optimized, so the assembly doesn’t match the source code. Returns in particular are often optimized so that there is only one actual return instruction in the assembly. So stepping through the code in a release build is not a reliable way to determine what’s going on.

    Once again, the proper way to debug release builds is using printfs and other mechanisms. You can still use the debugger to get a general sense of what’s going on, but you can’t rely on details like this.

    • 0