C++, C# newb question

[m371]

I know this is a totally newby question, but how do you actually debug. Is there like a line of code that you need to type out to debug or is it just base off the debug console where it shows the error messages and what not. Sometimes i even experienced errors when there is no errors to be found, i don't actually get it at all.

[JuztBe]

You add a breakpoint to the line of code from which you want to start debugging.

 

Then you run your project. Once it reaches breakpoint your code stops running. And in the window below you can see your variables and their values

Then using F10(steps over) and F11(steps in) you can progress your code step by step and see how your variables and their values are chaining at certain points of your code.

 

[P4ZD4]

https://msdn.microsoft.com/en-us/library/y740d9d3.aspx

[ChuckMaurice]

Yes, breakpoints, you beat me to the answer. Breakpoints are the key to good debugging.

 

You can also use functions like Console.WriteLine to output on the console. This is used somewhat like printf, cout, with this syntax:

Console.WriteLine("first variable: {0}, second variable: {1}", x1, x2);

 

This will also teach you how to write a log file, might be more practical sometimes.

[m371]

Whoa thanks for the fast reply, now i see how to properly debug. Was confused at first

[Yamoto42]

5 hours ago, jldjul said:

Yes, breakpoints, you beat me to the answer. Breakpoints are the key to good debugging.

 

You can also use functions like Console.WriteLine to output on the console. This is used somewhat like printf, cout, with this syntax:

Console.WriteLine("first variable: {0}, second variable: {1}", x1, x2);

 

This will also teach you how to write a log file, might be more practical sometimes.

@m371

For C# don't use console output for debugging.

There is another static class with the same API, System.Diagnostics.Debug.

Without getting into compiler services and conditional compilation too much, the Debug class is special.  When you compile for debug, it works as expected.  However, when you do a regular release build, the compiler just pretends you didn't make the calls.  this way you can still get your debug output when debugging, but your release code does not include all the extra (and time consuming) debug statements.

It also contains methods for making assertations...which are similarly ignored in release builds.  If you aren't familiar with assert statements, it is essentially a formal name for testing whether something is in the state you believe it to be before proceeding.  For example, if you believe (and your program requires) some integer X to always be between 1 and 9, but in the context of your method may be uncertain if it is always true (lets say its passes as an argument or something), you would make that assertment:

Debug.Assert(x > 1, "x <= 1");
Debug.Assert(x < 9, "x >= 9");

If either evaluate false, the program will stop and let you see what is going on.

If you're getting a lot of errors you aren't sure the cause of, then Assert will be your friend.  It means you are probably making assumptions about state that are not true.

 

It also posses a collection of TraceListeners, of which there are many subclasses.  Two that may interest you are TextWriterTraceListener, which passes output to a stream (you can use stdout or stderr), and FileLogTraceListener, which is specifically designed for log files, or in cases a versioned sequence of log files.

 

For example, to get debug output on stdout, just early in main:

Debug.Listeners.Add(new TextWriterTraceListener(Console.Out));

Often times in GUI applications, you might not have easy access to read stdout.  In console applications, you don't want to clutter up the console.  The user see's all that, quite frankly it will ultimately get in the user's way, even if you are the user.

 

There are also other programs that you can use to listen to debug output on test machines that are not development machines without using console output.  I typically use DebugView.

 

There is also a "Trace" class in that namespace with similar properties, but is not ignored by the compiler during standard release builds.  Trace is alright to use, however I would personally only save it for critical portions, that may still be uncertain at release.  Debug, however...use it as much as you can stand reading.