How to trace a program?
-
Every time I see a program I really want to know how it works. For example
for(x=0; x<=2; x++)
tracing...
x=0 0<=2 TRUE
x=1 1<=2 TRUE
x=2 2<=2 TRUE
x=3 3<=2 FALSEThere are some programs that I find it difficult to trace and how can I trace it even if it is hard to trace what I mean is how to determine the flow of the program? I just want to understand the algorithm of the program created by me and by others.
-
Every time I see a program I really want to know how it works. For example
for(x=0; x<=2; x++)
tracing...
x=0 0<=2 TRUE
x=1 1<=2 TRUE
x=2 2<=2 TRUE
x=3 3<=2 FALSEThere are some programs that I find it difficult to trace and how can I trace it even if it is hard to trace what I mean is how to determine the flow of the program? I just want to understand the algorithm of the program created by me and by others.
Step through the code using the debugger (VS?), or write to the output window of the debugger (eg. OutputDebugString()), or write to a log file? There are probably other ways as well.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
-
Every time I see a program I really want to know how it works. For example
for(x=0; x<=2; x++)
tracing...
x=0 0<=2 TRUE
x=1 1<=2 TRUE
x=2 2<=2 TRUE
x=3 3<=2 FALSEThere are some programs that I find it difficult to trace and how can I trace it even if it is hard to trace what I mean is how to determine the flow of the program? I just want to understand the algorithm of the program created by me and by others.
Don't trace. It's very hard to estimate the amount of information needed whithout flooding the output with pointless redundand information. Also the printed information is difficult to associate with the actual control flow, if the traced function can be called from different points in your code.
Judo Sarabia wrote:
how to determine the flow of the program?
Use a debugger, step through the code, and analyze the state of your program at your pace. You can check the call stack whenever you like to determine how you arrived at the function, and what happened earlier, or where the function arguments came from.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)