Typically I don't rely on debuggers, they aren't helping me much (for small programs there is no need, and for large complex ones they just aren't good enough).
This is what I do:
1. include good old-fashioned logging to a file, i.e. append one line of text telling what piece of code is executing, what the value is of some key variables, etc, all with a timestamp and a thread ID.
2. run the program a number of times; if it doesn't fail frequently enough, try and force it to fail more often by either stressing the system (less free RAM, more CPU load, whatever is relevant) or by increasing its activity (e.g. lowering its timer's periods or feeding it more input).
3. then compare all the logs, looking for a pattern at the moments of the crashes.
It is essential to have the latest information in the log file, therefore I open-append-close it for each and every line; and it may need locking for thread synchronization (although I typically try it without, as that is less intrusive).
All this (and anything you might do) may alter the timing a bit (and change thread synchronization, and cause more or fewer deadlocks), but most often it is adequate to pinpoint the problem. Of course, when the log file isn't detailed enough, I keep adding log statements. It all may sound antiquated, in my experience it works great, and all it takes is intimate knowledge about your app, and some energy; no need to get familiar with debugger idiosyncrasies.
Note: Having only one author for all the code is a big help; having lots of programmers, third party products, etc. all contributing to the crashing app may make it almost unsolvable.
If you tell the debugger to stop on exceptions (except for a few that might be expected in your application), the debugger will stop about half of the time exactly where the problem occurs.
If you are developing native C++ application and use STL then using checked iterators will also find most misuse although if will run much more slowly in that case. Generally the performance of C++ application is more affected by debugging than C# application (or safe C++/CLI).
Very often, it is possible to just put a breakpoint at the appropriate location and find the problem really fast. You just have to learn to use the debugger. Most of the time, simply inspecting a few variable give an hint on the problem. Well, maybe with some habit...
"Edit and continue" is also very powerful as you can often correct the code as soon as the error is detected (and maybe execute the code again after ensuring it won't cause undesirable side-effect).
It is possible to compile your C++ code as managed and then see if you can use Intellitrace. In Visaul Studio 11 Ultimate Preview, it works for safe C++/CLI code... I haven't tried other options.
Adding a lot of check in code (assertions) and tracing some information also help find problems.
In my case, most of the time, assertion and validation done in libraries (STL, .NET) and the use of a debugger let me find problems relatively quickly...
Well, maybe doing .NET development and using C# for more than half my code probably do help also...
Get windbg off the net'o'sphere and attach it to your exe. Set up the symbols, paths etc, and when it gacks up, do a (possibly) break and then !analyze -v and windbg will tell you exactly where it went wrong.
Great tool windbg, truly greatr. Massive, complex, quirky, but a hell of a good debugger.
I may be wrong but my understanding is that the information IntelliTrace assembles requires Reflection, managed code, or both. So, most likely, there are no tools with similar functionality for C++. I'm quite sure if it were possible, MS would provide it already.
With regard to random crashs, IME they are caused most of the time by inproper memory access, i. e. writing to or reading from memory areas that don't belong to you or the like. Your best bet is to look for tools that find memory problems. I'm using Insure++ for this purpose, which comes with the added advantage that it finds many problems before you even start the program. It is very slow though and requires a lot of additional memory, so it might be a good idea to look around for competitive products and see which suits your needs best.
Console Application? the old adage is: "When in Doubt, Print more Out". The Macro's
are realy handy there. Write a Dump Function, and do something like:
That is how you narrow down problems. You know your code, because you wrote it. It is hard to see how an Intellitrace debugger can have a better idea about what you wanted to write in the first place than that you can have. (It could work well in those highly structured Wizzard ridden area's such as Web Matrix. There the Author has no notion of what was written on his behalf, the only thing known to him there is what he wanted to achieve.
Commandline Programs? Not very likely Candidates for that technology.
When it trashes, you can narrow down where it happens. Also, occasional trashing tends to happen in retail code. Not much code is tested long enough in debug mode to catch an occasional trashing.
Even MS Word trashes occasionally, and that is also not always a software issue of your making.
Anyway, Debuggers don't work very well with retail code. LogFiles Do! Also, You Don't need to log in Text, You can create your own logging format, plus a (windows) app that can read and display the info.
If your code is perfect, but on occasion Windows trashes it anyways, there is little you can do (apart from re-writing Windows)
However, What are the Consequences of trashing. Did the User loose their input(inconvenience) or was an entire network or database crashed(Unmitigated Disaster). The former, Let it Go, if it is infrequent. The Latter: write your software mindfull of this, and be aware of the transaction technology you implement or wrote.
I Replied. What were you going to do if I didn't??( Or of nobody Did?)
Shoot all those that did not reply?? This community is not one of little slaves kept locked up until you issue a demand for information!
Please read the Posting notes before you ask a question on this forum!
I know that, Function pointer in C++ can point to an address of global function, or static public function of a class
typedef float (MyFunction)(float a, float b);
float add(float a, float b)
public static float add(float a, float b)
//Point to global function
fp = add;
//Point to public static function
fp = Math::add;
But it can not point to address of a function of a specified object.
For example, function add in calss Math is not static
public float add(float a, float b)
The following is impossible (compile error)
//Point to public function of specified object instance
Math*m = new Math();
fp = m->add;
But it is the thing i really want. Because i want to know function add is executed in context of what object (in this case we can know it is object m).
Above example is something like the concept Delegate in .NET.
Is there any design pattern to make such a delegate for C++?
You can link your application with static copies of the library rather than the shared DLL copies. There is a setting for the linker to do this.
Remember that linking statically increases the size of your EXE / DLL because all the required C Runtime Library and MFC / ATL libraries are included in your application. Of course, this is the tradeoff you make when you decide to not include the VS2005 redistributables in your kit / installation package.