Woa. That function looks like the spawn of hell. I would stick to making your own. I for one attempt to stay away from windows based functions when it''s so easy to make your own.
Alex Broadwin
A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."
"The answer is out there."
"Please help, I''m using Windows!"
debug - tracking function calls
Author
I think I might try both...
Simply because understanding and using that function seems like a challange, and rolling your own is always fun too.
Cheers,
-Mezz
Simply because understanding and using that function seems like a challange, and rolling your own is always fun too.
Cheers,
-Mezz
That sounds like a good idea. It''s always good to learn more whenever possible. I wish you the best of luck in getting the desired results. Happy coding!
Alex Broadwin
A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."
"The answer is out there."
"Please help, I''m using Windows!"
Alex Broadwin
A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."
"The answer is out there."
"Please help, I''m using Windows!"
A couple of additional thoughts:
1) Make sure that you use macros, so that you can turn the enter/exit calls off in the final release. Otherwise, they will be a huge penalty.
2) Realize that the program may run MUCH slower. I''ve seen similar mechanisms used, and depending on how much work you do in the enter/exit call, it can make the program many times slower.
3) Make sure to get all the exit points, else you may have very unhappy results. You can guard against this by passing the routine name into both the enter and exit macros, and testing the exits to make sure they match the top of the stack.
4) Exceptions are a problem. Decide how you want to handle them. I would suggest against trapping exceptions in all routines in order to pop the stack. Instead, you may have to either have a special exception handler, or pop the stack to match the given exit.
Stack walking would be more foolproof, and less overall work, but requires pretty intense OS/compiler-specific programming.
1) Make sure that you use macros, so that you can turn the enter/exit calls off in the final release. Otherwise, they will be a huge penalty.
2) Realize that the program may run MUCH slower. I''ve seen similar mechanisms used, and depending on how much work you do in the enter/exit call, it can make the program many times slower.
3) Make sure to get all the exit points, else you may have very unhappy results. You can guard against this by passing the routine name into both the enter and exit macros, and testing the exits to make sure they match the top of the stack.
4) Exceptions are a problem. Decide how you want to handle them. I would suggest against trapping exceptions in all routines in order to pop the stack. Instead, you may have to either have a special exception handler, or pop the stack to match the given exit.
Stack walking would be more foolproof, and less overall work, but requires pretty intense OS/compiler-specific programming.
The way I have this kind of thing set up in my code is fairly good. Mine has a controller class and a node class. The controller has a pointer to the last node to allow fast additions. Exit takes longer than entry in mine, but I have it set up to only keep stack info when DEBUG2 is defined. The same goes for asserts, which are pre-processed out if it isn''t defined. Simple to implement, and VERY handy. Anyway, as I said, best of luck to you.
Alex Broadwin
A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."
"The answer is out there."
"Please help, I''m using Windows!"
Alex Broadwin
A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."
"The answer is out there."
"Please help, I''m using Windows!"
Author
quote:
Stack walking would be more foolproof, and less overall work, but requires pretty intense OS/compiler-specific programming.
This is no lie. MSDN, Feb 99 BugSlayer column implements what we''ve been discussing.
It''s hard to read, shall we say.
-Mezz
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement