|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| C++ Gotchas | How Not to Program in C++ | Debugging C++ | Debugging Windows Programs | Debugging Applications for Microsoft .NET | Practical Debugging in C++ |
This page was created for my students to help them in their programming assignments. To use OS/languages effectively, you need to not just know the syntax and features of the particular language and API of the operating system, but you must develop an set of skills called debugging skills. Good books might help because they provide you some framework and a bit of the view on the problem. Among simple things not often mentioned in the books I would suggest the following:
- No matter what problem you fighting with, remain calm. Do not debug until you are fully exhausted. Switch activity. Take breaks.
- Panic paralyzes your ability to think through the problem and find a solution. Slow down and calm down.
- Understand that errors are inevitable and this is a fact of life to be lived with , not a problem to be solved.
- Get a night's sleep and try tomorrow (cannot be done if your deadline is tonight ;-)
- Take a pause and try it again
- Avoid typing errors, use fully debugged prototype as a template whenever possible. Many times I see that problems arise when students try to type too quickly or type in an example what can be simply copies from the file. Most textbooks provide an archive with the examples that should be used instead of typing them in (that does not mean that those examples are always correct ;-). Get a better keyboard: full side keyboard with a nice keys feel and a key-click (like IBM keyboards) helps to typing errors; copy constructs is you are unsure about syntax and then modify them. Remember that in programming languages typo is not always demonstrate itself in an obvious way. it much to do you bet to avoid them than to debug the program after you made one or several of them.
- Use the best editor you can get and get a list of typical language errors. Get a nice editor with syntax highlighting and language help. If the editor is integrated with the debugger (IDE environment) that's even better.
- Use GUI environment. If possible do not debug programs using telnet.
Telnet is too primitive and you should avoid it if you can. SSH is better and gives possibility to transfer files without opening additional FTP session. Use X windows, VNC or terminal server. You will have a better support for your keyboard and your monitor. With the regular terminal emulator the backspace and delete keys sometimes do not work correctly and need to be remapped. also unless you use screen (and you should) you cannot open more then terminal in regular emulator (without reconnecting again).
- Seek clarity. Use style books to simplify your programs and to create your own programming style. Simplify your program Avoid debugging everything at once. Remove non-essential modules if you face really complex problem. you can always add them later. Simplification helps you focus on a new task or way of approaching a problem.
- Don't flirt with deadlines.
If you start your work close to the deadline, you may run into trouble that you might not be able to resolve in time. In the real world, real deadlines mean either money lost or money gained. In the university world you can lower your score considerably but postponing the assignment till the last day. If you do something in a hurry the quality suffers and you might experience more debugging problem then if you have some space to breath. If you miss a deadline, you may lose some or all points for the assignment.
- Do not strive for perfection. Understand that any OS and any language was written for humans and by humans and thus is a language, full of ambiguity, inconsistencies, history, and culture.
The same is true about textbooks and teachers ;-).
The combination of hardware, networks, operating systems, and software gives rise to a high level of complexity. When problems arise, I have found it is best to try some troubleshooting techniques, then try something else, rather than trying to figure out exactly what went wrong (however, I do read error messages and look for any clues on the screen).
- Try to get as much help from your previous mistakes as possible.
People tend to repeat the same errors again and again. If you do not keep the log you can spend a lot of type bugling you head against the same wall, when the door is nearby. Each time you have found a non-trivial error in your program, write down the program fragment, the error messages and the solution. Next time it might save you a lot of time.
- Realize that there are many paths to getting things done.
There are usually many ways to accomplish a task. Don't get too dogmatic about finding the one and only one way to do it, nor get too over-involved in figuring out every way to do something.
- Make maximum use of Internet and your environment.
Use GUI environment is you can and have several windows opened at the same time. You can also use a second computer for reference if it is available.
- Have language help always opened.
- Convert example from the textbook into a webpages if you can and have this site always opened too.
Keep all of these windows up while working until you get your task done. Don't be afraid to bring up another Web browser, and keep the Web browser showing task information or reference information up. I've seen many students go through the trouble of bringing up a Web browser, following links to the assignment description, looking up a requirement for the assignment, then closing that Web browser, only to have to repeat the entire process when they need to look at the assignment description or reference information again. Don't be afraid to have as many windows open at the same time showing different information to get your work done.
|
You can use Honor System to make a contribution, supporting this site |
A P R E S S . C O M Books for Professionals, by Professionals ...
Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code
Chapter 7: Final Words of Advice
Visual Basic .NET Debugging Handbook
Comprehensive VB .NET Debugging
|
Debugging with GDB: The GNU Source-Level Debugger for GDB
by Richard M. Stallman, Cygnus Solutions
Debugging techniques in large systems
|
Books Program Debugging The Prevention and Cure of Program Errors
|
| C++ Gotchas | How Not to Program in C++ | Debugging C++ | Debugging Windows Programs | Debugging Applications for Microsoft .NET | Practical Debugging in C++ |
[Dewhurst2002] C++ Gotchas Avoiding Common Problems in Coding and Design
by Stephen C. Dewhurst (Author)
Really not bad., April 14, 2003
Reviewer: A reader from Erlangen, Germany There are dozens books about C++ on the market and this one is clearly under the top ten. It's a wonderful book for beginners and programmers at an intermediate level. For the pros it's fun to read it, because: I made all this mistakes a few years ago. The perhaps only flaw ( I found in the whole book only one real mistake, or my compiler (gcc) is wrong , and I know it's not) of this book: it's too short. If you are making your first steps in C++, then buy this book.
A must read, February 18, 2003
Reviewer: alefinus (see more about me) from El Dorado Hills, CA United States This is a wonderful book. Not a usual list of trivial advices and recipes, but a collection of serious considerations on how to write code that will survive years of maintenance.
I haven't come to this conclusion right away. At first, I was a bit irritated by what I had thought were the author's biases and self-confidence, but as I kept reading, I began appreciating and even enjoying his candid and confident style that communicated strong experience of dealing with the issues. Not since the time when the ARM ("The Annotated C++ Reference Manual" by Margaret A. Ellis and Bjarne Stroustrup) and Stroustrup's "The C++ Programming Language" were published years ago have I read a C++ book that impressed me as much! If Stroustrup's books focus on the description of C++ facilities, this book concentrates on its programming practice. The author's knowledge of the C++ standard and the compiler mechanics makes his arguments very compelling.
Although anybody familiar with C++ will benefit from this book since it covers a wide range of C++ features, as well as programming and support issues, the book should appeal most of all to the mature audience: one has to be mature to understand the value in developing a program that will sustain years of maintenance by others rather than the one that will only run most of the time without crashing.
Ignore the reviewer from Sweden, January 31, 2003
Reviewer: A reader from Palo Alto, CA Having been in software development for many years, the last twelve using C++, I can say from experience that the author has assembled an accurate collection of problems I encounter over and over again. I have worked with legacy source code from Microsoft, Adobe Systems and other lesser known software companies that have some of the problems described in this book. These instances are not an indication of incompetence on the part of the original programmers, but rather a reflection of the realities of the business: deadlines need to be met and rarely do we have the time fiddle with code to make it into picture perfect C++. And if it works properly as it is, then don't fix something that is not broken.
Beginning C++ programmers will get a lot out of this book. This is especially true if you are migrating from C and need to break a few bad habits. Experienced C++ developers will not get that much out of it, but the author has many interesting points that are worth checking out.
The reviewer from Sweden is either an academic pinhead who has never participated in a large commercial software development effort that someone would actually want to pay money for, or he / she / it stopped reading the book after the first three or four sections.
To sum this book up: If you DON'T need to ask yourself the questions the author addresses in this book, then you are not doing any serious C++ software development!
[Qualline2003
]
How Not to Program in C++ 111 Broken Programs and 3 Working Ones, or Why Does 2+2=5986
by
Steve Oualline
Only for extreme novice C++ programmers, April 4, 2003
Reviewer: A reader from an undisclosed location The concept of this book is good, but the execution is seriously lacking.
The "bugs" in Mr.Oualline's programs are the kinds of errors only the most unskilled novices would make: a missing space character in a format statement; accessing a 5-element array with index values of 1 thru 5; a class whose constructor allocates storage but whose destructor doesn't release the memory. Trivial, easy-to-spot errors that don't really expand anyone's grasp of C++.
To add insult to injury, large portions of the book are filled with Mr.Oualline's tiresome war stories and aphorisms.
A much better source of knowledge is "C++ Gotchas", any of Scott Meyers' books, or the "C++ FAQ".
Just Plain Fun!!!, March 31, 2003
Reviewer: Brad (see more about me) from Fishers, IN United States Okay, maybe I should say, just plain fun in a geeky kind of way. This book is relatively inexpensive, thus making it well worth the price. If you program in C++ (or even in C, C#, or Java), then you will most likely enjoy this book.
Unlike most computer books, this is not a book you read in order to learn how to to something. Rather, this is a book you read (1) to see if you already know how to do something, (2) if you like solving puzzles, (3) if you want to learn about a number of typical 'gotchas'.
This book presents listings (about 111+). Each seems to have something specifically wrong with it. You try to figure out the issue with a hint. You are can then get additional hints using a jump table. You are also given the answer as to what the gotcha is.
The book also contains a large number of trivia type information. This is folklore, funny stories, and more.
This is a book that I find myself picking up over and over to read just a little farther. It is fun. It is interesting. I'm even learning a thing or two. I've enjoyed it so much, I'll be writing a review on it for CodeGuru.com!
Congratulations to Steve Oualline on putting together one of the few fun-to-read computers books.
[McKey2000] Debugging Windows Programs Strategies, Tools, and Techniques for Visual C++ Programmers
by Everett N. McKay (Author)
"must have" for general debugging, April 8, 2002
| Reviewer: developer from England |
In my experience, programmers fall into two categories: general (majority) and advanced (few); advanced ones understanding register and stack dumps etc, general ones being lost. This book covers the more general programmer, Robbins book the advanced. Comparing the two, you could write your own debugger and your own "core" dumps (which you can then examine) from Robbins book; with this one you can't, but it covers useful stuff missing from Robbins book (eg. PE format, address space partitioning). As such they have some overlap but supplement each other. Both books are essential to serious developers. I have one gripe with this and Robbins book: neither suggests outputting the mixed source/assembly/machine_code (.COD files); these are essential (without a .PDB) if a crash occurs so that the offending instruction etc. can be found, as many instructions usually follow a line of source; secondly, function locals only show in .CODs (as offsets from EBP) so making them easy to locate on a stack trace.
No Mercy Debugging, July 26, 2001
| Reviewer: dev1zero (see more about me) from Bellevue, WA United States |
C++ bugs can be very difficult to find and can bring tears to the eyes of a programmer easily.(You know the bug is there but you just cant find it to save your life!)
After reading the first few chapters of this book, I knew it was a winner. This book shows ways to find bugs in different kinds of C++ programs MFC,COM etc.
The most important however is the chapter on memory bugs (a real pain)
If you need to hunt down bugs, get this book and your monitor is less likely to end up smashed from your frustrations.
This book also points the reader to a lot of other books which should make a
better programmer of anyone who bothers to buy them.
Hands down best book on Windows/VC++ debugging, September 7, 2001
| Reviewer: dwstark (see more about me) from Santa Rosa, CA United States |
If you write sofware for Windows using VC++, you cannot afford to not have this
book. End of story. Everything that I'd scoured MSDN, MSJ, and news groups for the
last 5 years to figure out about how Windows works from a user mode program mechanics
point of view (PE format, DLL rebasing, symbols, etc) and debugging techniques is
in this book (plus more stuff that I'd not yet found out about). It is well written
and understandable. It works as a good overview of the topics and as a reference
for dealing with a partiular problem, like post-mortem debugging, debugging memory
or multi-threading problems, etc. Pick one up, you won't regret it.
[Robbins2003] Debugging Applications for Microsoft .NET and Microsoft Windows
by
John Robbins
| Price: | $41.99 |
Below the belt..., September 23, 2003
| Reviewer: Paul Selormey (see more about me) from Toyohashi, Aichi Japan |
I bought this book to get a complete knowledge of the .NET framework debugging and got nothing. May be the .NET in the title applies to the fact that the author is using the VS.NET. If you have got the author's previous book on debugging then there is no need to waste money on this one.
It discusses mainly C/C++ debugging in a typical MFC style (ASSERT/VERIFY etc).
Here is the content at a glance:
1. Bugs: Where they come From and How you Solve Them
2. Getting Started Debugging
3. Debugging During Coding
4. Operating System Debugging Support and How Win32 Debuggers Work
5. Advanced Debugger Usage with Visual Studio .NET
6. Advanced .NET Debugging with Visual Studio .NET
7. Advanced Native Code Techniques with Visual Studio .NET
8. Advanced Native Code Techniques with WinDGB
9. Extending the Visual Studio .NET IDE
10. Managed Exception Monitoring
11. Flow Tracing
12. Finding Source and Line Information with Just a Crash Address
13. Crash Handlers
14. Debugging Windows Services and DLLs That Load into Services
15. Multithreaded Deadlocks
16. Automated Testing
17. The Debug C Run-Time Library and Memory Management
18. FastTrace: A High-Performance Tracing Tool for Server Applications
19. Smoothing the Working Set
Appendixes.
As you can tell, there is hardly a .NET stuff to pay for, so for those of us owing the author's previous debugging book, this is just a second edition with .NET appended to confuse buyers!
[Ford&Teorey2002]
Practical Debugging in C++
by Ann R. Ford (Author), Toby J.
Teorey (Author)
[Pappas&Murray2000]
Debugging C++: Troubleshooting for Programmers
by Chris H. Pappas, William H. Murray
Avg. Customer Rating:
Decent for beginner Windows programmers, September 10, 2001
| Reviewer: A reader from Vero Beach, FL United States |
I was pretty excited when I first got this book, but was pretty disappointed after reading it.
First off, the title is misleading, focusing on Windows rather than C++. Since I am mainly a Windows programmer, though, this didn't phase me too much. However, the book often seemed to be a manual for the Visual C++ debugger rather than an insightful narrative on the debugging process. Although I realize examples have to be short and to the point, I was often insulted by the ridiculously simple errors the authors presented. The section on inline assembly debugging is almost useless. A much better approach would be examining the assembly language that the Visual C++ compile generates, rather than creating simple ASM programs with obvious mistakes.
I would have much rather seen a book about preventing bugs, and techniques that
can be used to accomplish this goal. While this is certainly not that book, it would
be useful for something just getting started with Visual C++, though anyone beyond
a novice would probably be as disappointed as I was.
Buy John Robbins 'Debugging Applications' instead., March 4, 2002
| Reviewer: A reader from Hobart, TAS, Australia |
Like I said, the above sums up my advice. I'd suggest only absolute beginners would write a good review for this book, because they don't know any better. One section alleges that a programmer who teaches themself C++ will get fired, because they would use the line
i = i + 1;
not realising they SHOULD use
i++;
This is funny on SO many levels.
1. Who would fire someone for this ?
2. Why can't people find this syntax for themselves ?
3. He crows about increased efficiency, but i++ creates a tempory, he wants ++i
for this claim
4. He was talking specifically about people teaching themselves in migration from
C, which, as you know, supports i++.
He goes on to list the STL containers, misses half of them and goes on to explain why STL containers are better than containers based on templates ( which is the bedrock of STL ).
His understanding is obviously lacking, but this does not stop him from writing about a topic if he thinks it will help sell his book.
John Robbins book, on the other hand, is indispensable. If you don't own it,
you need to. It is everything this book could have been and more. John is the author
of MSDN's 'Bugslayer' column, and he knows what he is talking about.
by Keith Bugg
Avg. Customer Rating:
Paperback
Used & new from
$2.10
The book could have been named: "Debugging Visual C++ for Dummies". It's contents in certain chapters are not detailed enough to actually teach you how to use to the various debugging tools to full potential. Chapters 4(The Visual C++ Debugger) and 5(Additional Debugging Tools) fit the above description. The author does provide some good suggestions to bolster your debugging process, but to be a true tutorial for the "intermediate" programmer, more code examples and actual use of the debugging features is required. Hopefully the next edition will go from an IDG "...Dummies" clone to a "Visual C++ Debugging Bible". |
Not very useful., January 25, 1999
| Reviewer: A reader |
While this book did offer a few pieces of good information, I was very disappointed overall. Even though the book calls itself "A Tutorial-Based Desktop Reference", very little, if any of the book was in the form of a tutorial.
The first part, which deals with Windows memory issues, did at least have some code samples, but no tutorials. Once he started talking about the Visual C++ debugger and other tools, he just gave brief descriptions without saying why or when you would want to use them.
The information in the book is about the same quantity and quality you can find in Visual C++ help. In fact, after reading one topic, I looked it up in the help and was surprised to find that it said almost exactly the same thing, word-for-word. The author added one or two sentences of his own that didn't give me any useful information.
I was looking forward to the section on third party tools, but I found that it was basically a listing of features with nothing to tell me whether the tools would be worth buying, much less instructions on how to actually use them.
There is some useful information, such as a description of how memory is managed
in 32-bit Windows. But the same thing can be found in other books. And most of the
rest of the book can probably be found in the Microsoft help files or on the outside
of the third party tool packages. The best thing I can say about this book is that
it puts all of this together.
This book was written with the intermediate developer in mind. I discuss basic issues impacting the debugging phase of software development with Visual C++ ranging from design to testing. Topics include the ASSERT macros, the TRY-CATCH macros, using the debugger, stack probes and stack unwinding, etc. I also provide an overview of third party development tools that aid the debugging process |
Out of Print--Limited Availability
Defensive Programming in C++: Program Planning, Diagnosis, and Debugging
by Scott Robert Ladd
Out of Print--Limited Availability
Turbo C: The Art of Advanced Program Design, Optimization, and Debugging/Book & Disk
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Created May 16, 1997; Last modified: May 04, 2008