Were you taught debugging

[nuzzle]

I have a preferred list of debugging techiques. From most preferred to least preferred:

Debugger
Log File
Event log
Trace output
Message box

Blindly trying things hoping it will work is the worse.

This list is pure nonsense.

For example why is a debugger better than the rest?

[Arjay]

This list is pure nonsense.

For example why is a debugger better than the rest?

Chill out, baby - I wrote that it's my preferred list. If you get better mileage out of some other technique(s), good for you.

For me, I can pinpoint a problem faster in a debugger than using any other technique.

[nuzzle]

For me, I can pinpoint a problem faster in a debugger than using any other technique.

Sure you can but you're not always available, are you?

[Arjay]

Sure you can but you're not always available, are you?

I can be. Send me a pm and we can discuss rates.

[Lindley]

I'm not saying you shouldn't use a debugger. I'm saying you should strive for having not to use one.

I suppose my increased usage of STL and Boost are following this philosophy as well. I'm a big fan of the "if it compiles it's probably right, and if it's not it'll throw an exception" style of coding.

Asserts being part of that category, since even though they're not *really* exceptions they behave the same in gdb---they halt execution at the point of failure for you.

[nuzzle]

I suppose my increased usage of STL and Boost are following this philosophy as well. I'm a big fan of the "if it compiles it's probably right, and if it's not it'll throw an exception" style of coding.

What I suggested was to not introduce any bugs in the first place. Then you don't need a debugger, do you?

Not to introduce any bugs (that needs debugging) you use a proper program development method, like for example Stepwise Refinement.

[Lindley]

What I suggested was to not introduce any bugs in the first place. Then you don't need a debugger, do you?

Good in theory, impossible in practice.

Not to introduce any bugs (that needs debugging) you use a proper program development method, like for example Stepwise Refinement.

Such things help. However, they can't prevent all bugs, so as I said before: Debugging is a multi-approach discipline.

[nuzzle]

Good in theory, impossible in practice.

You're wrong. Stepwise Refinement is always practible.

[Lindley]

I didn't say anything about your pet method. I said it's impossible to avoid bugs entirely all the time. But you'd know that if you bothered to pay attention to which part I quoted.

[nuzzle]

I didn't say anything about your pet method. I said it's impossible to avoid bugs entirely all the time. But you'd know that if you bothered to pay attention to which part I quoted.

It's not my pet method. In fact Stepwise Refinement is the mother of all program development metods.

Note that a debugger doesn't help you avoid bugs.

[Lindley]

Note that a debugger doesn't help you avoid bugs.

Of course not. It helps you solve them. That's why it's called a "debugger".

[JohnW@Wessex]

The debugging tools I use are all dependent on the nature of the bug I'm trying to find.

I find that algorithmic bugs are often easier to solve using the debugger; I can see the variables change, modify them if necessary and step into functions to see where execution differs from that I expected.
In simple cases I may just bring up a dialog box with the values of interest.

Other problems can sometimes be intermittent; Our applications are realtime, multi-threaded and asynchronous. The debugger is usually useless in this case for tracking down non-complient behaviour. In this case I resort to our event log. Our event logging system allows us to enable/disable logs through an external file, so event log code tends to stay in the source. The overhead of testing for an enabled/disabled log has been designed to be extremely low.

As a general rule in building the code, I tend to write in a functionally modular style; Each area of functionality is as self contained as possible and as near as possible, testable in isolation. Any functionality that can be identified as part of a more general case will often be written in a generic fashion and added to our library, often customised by the use of polymorphism or dependency injection. This allows a resource of tested and debugged code to be used with confidence in new applications.

At the lowest level, exceptional errors, such as out of bounds or illegal parameters, are trapped using exceptions which log the class, function and reason. These can be switched off using a compiler switch when necessary for performance critical code.

In fact Stepwise Refinement is the mother of all program development metods.

I think that modular construction is a necessary addition to that, otherwise software can grow into a large unmaintainable monster, even though it may be functionally correct.
Our old library contains an image class that started simple. Stepwise development saw it increase in functionality over the years. Unfortunately it started to become a massive class that contained every 'useful' function that various coders came up with. Our new library now splits the responsibility in STL fashion i.e. container/iterator/algorithm. Now stepwise development involves merely devising an algorithm that conforms to the iterator interface.

[Peter_APIIT]

I mostly find debugging the program very difficult when using library(.lib) or dll.

What is your opinion ?

[Arjay]

Our event logging system allows us to enable/disable logs through an external file, so event log code tends to stay in the source. The overhead of testing for an enabled/disabled log has been designed to be extremely low.

When I use logging, I prefer a logging mechanism that is capable of different log levels and has indenting. With this logging framework, I generally log when I enter and leave method (usually logging additional info in these calls as well). I just find it easier to read the log file that clearly shows where you've entered and exited methods as opposed to a left-aligned log.

[GCDEF]

I mostly find debugging the program very difficult when using library(.lib) or dll.

What is your opinion ?

With Visual C++ debugging a DLL or .lib is no different than debugging an exe.