I guess you've all seen c++ apps that display an error along with the line of code that causes it. It's usually used in games, but other apps use it, too.
I heard that this can be implemented using macros, but I can't seem to find any resource on the interwebs.
Anyone has any ideas how this is implemented?

are you talking about assertion failed errors ?

those are caused by the assert macro (which basically takes an expression, if it evaluates to true nothing happens, if it evaluates the false the program displays an error and exits) , normally those aren't used in release builds though. (most assert macros are written so that they'll be automatically stripped out unless its a debug build)

[quote name='Tayron' timestamp='1308127313' post='4823535']
I guess you've all seen c++ apps that display an error along with the line of code that causes it. It's usually used in games, but other apps use it, too.
I heard that this can be implemented using macros, but I can't seem to find any resource on the interwebs.
Anyone has any ideas how this is implemented?

are you talking about assertion failed errors ?

those are caused by the assert macro (which basically takes an expression, if it evaluates to true nothing happens, if it evaluates the false the program displays an error and exits) , normally those aren't used in release builds though. (most assert macros are written so that they'll be automatically stripped out unless its a debug build)
[/quote]

For a large commerical game that is performance intensive maybe. But often times it is helpful to leave asserts in the release build. I've had cases where I could fix bugs because users reported an assertion failure. Without asserts it would be significantly harder, if at all possible to locate such bugs. I'd say when in doubt, leave them in.

You can more or less automate a crash log by walking the stack, and providing some (at a minimum c++ public symbols). If there is enough information avialable to the debug API's (via pdb files, access to microsoft's symbol servers, your own symbol server etc), you will get line numbers, function names, and other juicy details.

http://stackwalker.codeplex.com/


You basically need to have all your exception classes walk the stack with the code I linked above in their constructors, and also hook up a SEH handler filter to catch system exceptions (access violation, divide by zero, etc), and dump the stack in there too. It is quite useful as end-user call stacks can vary quite a bit due to the presence of other DLLs on the system.