On Oct 9, 2011, at 17:26 , Todd wrote: #ifdef __BUILD_MAC__ || __BUILD_LINUX__
int main( int argc, char *argv[] )
#else if __BUILD_WIN__
int WINAPI WinMain( HINSTANCE hInst, HINSTANCE hPreInst, LPSTR
lpszCmdLine, int nCmdShow )
#endif
{
int jason=0;
try
{
#ifdef __BUILD_MAC__ || __BUILD_LINUX__
std::auto_ptr<CPLAT::CP_Startup> platformStartup(CP_new
CPLAT::CP_Startup(argc, argv));
#else
std::auto_ptr<CPLAT::CP_Startup> platformStartup(CP_new
CPLAT::CP_Startup(hInst, hPreInst, lpszCmdLine, nCmdShow));
#endif
FXHostApp application;
application.Run();
}
catch(...)
{
}
return( 0 );
}
So if I place a break point on the int jason=0; the debugger does
stop, It says at that line number, but the red arrow is placed at
'std::auto_ptr<CPLAT::CP_Startup> platformStartup(CP_new
CPLAT::CP_Startup(argc, argv));' line.
If I try to do a step over when stopped at the int jason=0; It just
goes to return(0);
Like the try{} is being ignored some how. This used to work just fine.
You're making some incorrect assumptions about the debugger here. When you set a breakpoint on a source line, the debugger actually stops on the first *executable* statement on or after that line. It's quite likely that the compiler recognized 'int jason= 0' as a dead store, and optimized it away. That would mean it's stopping at the expected place -- the next executable statement.
Did you have other breakpoints set? If you step at the place it stopped, and that statement threw an exception, the next executable line in this function after *that* could well have been the return statement.
Did you check for error messages in the Console log?
You're going to have to be a bit more focused in your debugging. If you suspect the debugger is not accurately showing you the execution flow in source code terms (and the debugger is far less than perfect from that point of view), then you might have to add some more code (NSLog could be your friend here) to trace where execution goes.
|