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.
Besides the setting for the C RTL (/MT etc...) you also need to check the Configuration Properties -> General for the "Use of MFC" and "Use of ATL". Both of those have a selection for "in a static library". The default to "use standard windows libraries" which means "shared DLL".
I use VS2008 but I think they are in the same place in VS2005
Last Visit: 31-Dec-99 18:00 Last Update: 29-Sep-23 1:22