add watch shows undefined identifier visual studio 2012, cpp - c++

I encounter the strangest behavior in VS 2012 (I'm writing in cpp).
I click "add watch" on a variable and it says "identifier is undefined".
Here's an example of the code:
for (int j=0;j<32;j++)
{
unsigned char curValue=desc1.at<unsigned char>(0,j);
printf("%s\n",curValue);
}
I had to use printf to show the value of curValue. lol.
Has anyone encountered such behavior?
Edit: more strange this occur. When debugging the following code:
int b1[8];
for (int k=0;k<7;k++)
b1[k]=0;
char q=curValue;
int t=0;
while (q!=0){
b1[t++]=q%2;
q=q/2;
}
The debugger just skips the loop with b1[k]=0;
Please note curValue is undefined even inside the loop.
Thanks!

As Joachim said: curValue is defined inside the loop. If watch window in visual studio see it as undefined value then you should turn off Compiler optimization.
Compiler optimization default is /O2 optimize for speed. To turn it off :
Go to project, right click and choose properties
Configuration Properties->C/C++->Optimization
select optimization , and change it from Maximize Speed (/O2) to Disabled (/Od)

I had optimizations turned on. That messed up my debugging.

Without the printf, the first loop has no side effects and is thus likely optimized away in an optimized build. In the second example, the loop that initializes the small array to 0 is probably replaced with an initialized data section.
You should probably try to debug with an unoptimized build.
Also note that the Visual Studio debugger has pretty good visualizers for the standard containers. So if the whole point of the first loop was just to peek at the contents of desc1, you can probably just examine it directly in the debugger.

Remember that the variable curValue is only valid inside the loop, if you try to add it to the watch when you're not in the loop then the variable is not defined.

Because curValue gets out of scope outside the for loop.
Also note that you should use %c in printf to print char. %s is used for C-style strings.
printf("%c\n",curValue);

Variable curValue is only valid inside the loop. If you will try to add it to the "watch" when you aren't in the loop, then your variable will be not defined.
Note: Better you should print this:
printf("%c\n",curValue);
Instead of this:
printf("%s\n",curValue)

Restart Visual Studio. Worked for me.

Related

Is it possible to set a multiple conditions Breakpoint in Visual Studio 2013?

does anyone knows if its possible to set a multiple condition breakpoint on a specific line in Visual Studio 2013 (C++) ?
I was trying using the '&&' but it didn't worked. I also couldn't find an answer on MSDN.
the breakpoint that i wanna set is inside the WindowProc, the condition that i wanna set is - message = WM_MOUSEMOVE, WPARAM = MK_LBUTTON
thanks in advace, Igor.
WM_MOUSEMOVE is a macrodefinition and gets replaced in the source code by the compiler during compilation. It is unknown to the debugger, so you can't use it in a breakpoint condition expression; use explicit number constant instead.
BTW, are you aware you used operator '=', which is not the same as '=='...?
Using && is allowed and should work. What's more, a lot of common C++ expressions are allowed. This page lists what is and what isn't allowed.
Note that using this kind of breakpoint will considerably slow down your application. To the point where debugging is no longer feasible. This might be what has led you to believe && isn't allowed. To overcome this particular problem you might want to use a construct like this:
//untested code
#ifdef _DEBUG
if(condition a && condition b)
{
//either output something (option A)
std::cout << "condition a and b are true"
//or create a nop statement (option B)
__nop(); //and set a breakpoint
//or create a 'nop statement' with compiler warning (option C)
int breakpoint = 0;
}
#endif
This will yield much better performance.
Since this code is only compiled in when you are compiling in debug, you can leave this bit of code in (and option B would therefore be the best). If you however want to be reminded to remove the debugging clause, option C is probably the way you wanna go. As this will generate a variable breakpoint is declared but never used warning. As kindly suggested by borisbn.
If you are using this statement a lot it's probably most useful to wrap it into a precompiler macro.

Why is passing a char* to this method failing?

I have a C++ method such as:
bool MyClass::Foo(char* charPointer)
{
return CallExternalAPIFunction(charPointer);
}
Now I have some static method somewhere else such as:
bool MyOtherClass::DoFoo(char* charPointer)
{
return _myClassObject.Foo(charPointer);
}
My issue is that my code breaks at that point. It doesn't exit the application or anything, it just never returns any value. To try and pinpoint the issue, I stepped through the code using the Visual Studio 2010 debugger and noticed something weird.
When I step into the DoFoo function and hover over charPointer, I actually see the value it was called with (an IP address string in this case). However, when I step into Foo and hover over charPointer, nothing shows up and the external API function call never returns (it's like it's just stepped over) and my program resumes it's execution after the call to DoFoo.
I also tried using the Exception... feature of the VS debugger (to pick up first chance exceptions) but it never picked up anything.
Has this ever happened to anyone? Am I doing something wrong?
Thank you.
You need to build the project with Debug settings. Release settings mean that optimizations are enabled and optimizations make debugging a beating.
Without optimizations, there is a very close correspondence between statements in your C++ code and blocks of machine code in the program. The program is slower (often far slower) but it's easier to debug because you can observe what each statement does.
The optimizer reorders your code, eliminates variables, inlines functions, unrolls loops, and does all sorts of other things to make the program fast. The program is faster (often much faster) but it's far more difficult to debug because the correspondence between the statements in your C++ code and the instructions in the machine code is no longer there.

w8004 compiler warning BDS6 c/c++

It is a best practise to initialise a variable at the time of declaration.
int TMyClass::GetValue()
{
int vStatus = OK;
// A function returns a value
vStatus = DoSomeThingAndReturnErrorCode();
if(!vStatus)
//Do something
else
return(vStatus);
}
In the debug mode, a statement like this int vStatus = OK; is causing no issues during DEBUG MODE build.
The same when build in RELEASE MODE, throws a warning saying:
w8004: 'vStatus' is assigned a value that is never used.
Also, i am using the same variable further down my code with in the same function,like this if(!vStatus)and also I return the value of return(vStatus);
When I looked at the web for pointers on this debug Vs Release, compilers expect you to initialise your variable at the time of declaring it.
I am using Borland developer studio 6 with windows 2003 server.
Any pointers will help me to understand this issue.
Thanks
Raj
You initialise vStatus to OK, then you immediately assign a new value.
Instead of doing that you should initalise vStatus with a value that you're going to use.
Try doing the following instead:
int TMyClass::GetValue()
{
// A function returns a value
int vStatus = DoSomeThingAndReturnErrorCode();
if(!vStatus)
//Do something
else
return(vStatus);
}
Edit: Some clarification.
Initialising a variable, only to never use that value, and then to assign another value to the variable is inefficient. In your case, where you're just using int's it's not really a problem. However, if there's a large overhead in creating / copying / assignment for your types then the overhead can be a performance drain, especially if you do it a lot.
Basically, the compiler is trying to help you out and point out areas in your program where improvements can be made to your code
If you're wondering why there's no warning in debug mode, it's because the passes that perform dataflow analysis (which is what finds the problem) are only run as part of optimization.

Visual Studio 2005 C compiler problem when optimizing a switch statement

General Question which may be of interest to others:
I ran into a, what I believe, C++-compiler optimization (Visual Studio 2005) problem with a switch statement. What I'd want to know is if there is any way to satisfy my curiosity and find out what the compiler is trying to but failing to do. Is there any log I can spend some time (probably too much time) deciphering?
My specific problem for those curious enough to continue reading - I'd like to hear your thoughts on why I get problems in this specific case.
I've got a tiny program with about 500 lines of code containing a switch statement. Some of its cases contain some assignment of pointers.
double *ptx, *pty, *ptz;
double **ppt = new double*[3];
//some code initializing etc ptx, pty and ptz
ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;
The middle statement seems to hang the compiler. The compilation never ends. OK, I didn't wait for longer than it took to walk down the hall, talk to some people, get a cup of coffee and return to my desk, but this is a tiny program which usually compiles in less than a second. Remove a single line (the one indicated in the code above) and the problem goes away, as it also does when removing the optimization (on the whole program or using #pragma on the function).
Why does this middle line cause a problem? The compilers optimizer doesn't like pty.
There is no difference in the vectors ptx, pty, and ptz in the program. Everything I do to pty I do to ptx and ptz. I tried swapping their positions in ppt, but pty was still the line causing a problem.
I'm asking about this because I'm curious about what is happening. The code is rewritten and is working fine.
Edit:
Almost two weeks later, I check out the closest version to the code I described above and I can't edit it back to make it crash. This is really annoying, embarrassing and irritating. I'll give it another try, but if I don't get it breaking anytime soon I guess this part of the question is obsolete and I'll remove it. Really sorry for taking your time.
If you need to make this code compilable without changing it too much consider using memcpy where you assign a value to ppt[1]. This should at least compile fine.
However, you problem seems more like another part of the source code causes this behaviour.
What you can also try is to put this stuff:
ppt[0]=ptx;
ppt[1]=pty; //<----- this statement causes problems
ppt[2]=ptz;
in another function.
This should also help compiler a bit to avoid the path it is taking to compile your code.
Did you try renaming pty to something else (i.e. pt_y)? I encountered a couple of times (i.e. with a variable "rect2") the problem that some names seem to be "reserved".
It sounds like a compiler bug. Have you tried re-ordering the lines? e.g.,
ppt[1]=pty;
ppt[0]=ptx;
ppt[2]=ptz;
Also what happens if you juggle about the values that are assigned (which will introduce bugs in your code, but may indicator whether its the pointer or the array that's the issue), e.g.:
ppt[0] = pty;
ppt[1] = ptz;
ppt[2] = ptx;
(or similar).
It's probably due to your declaration of ptx, pty and ptz with them being optimised out to use the same address. Then this action is causing your compiler problems later in your code.
Try
static double *ptx;
static double *pty;
static double *ptz;

How do you add conditional breaking based on another breakpoint being hit? Visual C++

I have a bunch of generic code that is used a lot, which i'd like to poke into in order to deal with a bug in a certain specific case.
So I'd like to break on a set of breakpoints only if some other breakpoint has been hit. Is there a way to do this in Visual 2005? I'm using C++ code.
Thanks!
Please remember you can disable a breakpoint - it might be easier/more efficient/cleaner (then adding debug flags to your code and recompiling for example) to just disable the second breakpoint, wait till the first one breaks and then enable the second one in your breakpoints window - it takes just two mouse clicks each time you debug... :)
If the trigger logic is complex enough, sometimes I find it easier to just add a DebugBreak(); call into the source.
Have your first breakpoint change the value of some variable to a magic value (you can use a conditional breakpoint, with an expression which changed the variable and then returned true). Then, have the second breakpoint break when the variable is at that magic value. e.g.,
int debug_flag = 0;
First breakpoint condition:
debug_flag = 0xdeadbeef, true
Second breakpoint condition:
debug_flag == 0xdeadbeef
Ten years later...
An easy way to do what the OP wants would be to use the immediate window to define a global variable, and use it as suggested by #chris-jester-young in breakpoints conditions.
Did the trick for me anyway.