This list is pure nonsense.Quote:
Originally Posted by Arjay
For example why is a debugger better than the rest?
Printable View
This list is pure nonsense.Quote:
Originally Posted by Arjay
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.Quote:
Originally Posted by 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?Quote:
Originally Posted by Arjay
I can be. Send me a pm and we can discuss rates. :)Quote:
Originally Posted by 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.Quote:
Originally Posted by nuzzle
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.
What I suggested was to not introduce any bugs in the first place. Then you don't need a debugger, do you?Quote:
Originally Posted by Lindley
Not to introduce any bugs (that needs debugging) you use a proper program development method, like for example Stepwise Refinement.
Good in theory, impossible in practice.Quote:
Originally Posted by nuzzle
Such things help. However, they can't prevent all bugs, so as I said before: Debugging is a multi-approach discipline.Quote:
Not to introduce any bugs (that needs debugging) you use a proper program development method, like for example Stepwise Refinement.
You're wrong. Stepwise Refinement is always practible.Quote:
Originally Posted by 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.
It's not my pet method. In fact Stepwise Refinement is the mother of all program development metods.Quote:
Originally Posted by 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".Quote:
Originally Posted by nuzzle
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.
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.Quote:
In fact Stepwise Refinement is the mother of all program development metods.
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.
I mostly find debugging the program very difficult when using library(.lib) or dll.
What is your opinion ?
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.Quote:
Originally Posted by JohnW@Wessex
With Visual C++ debugging a DLL or .lib is no different than debugging an exe.Quote:
Originally Posted by Peter_APIIT