I'm using Visual C++ 2005 Express Edition and despite all of my Googling have a problem I can't quite seem to find a solution to. I'm creating a program that uses the Platform SDK as well as OpenGL, and within the IDE it works fine. No problems. However, once I take the .exe outside of the IDE it doesn't work. It makes the window then crashes before it has a chance to draw on it. I've no idea where to begin finding out what's wrong because 1) it works in the IDE perfectly, so that just confuses me, and 2) the error message I get is non-helpful (it's that generic one.) All I can guess is that there is some file that needs to be linked into the project that the IDE has access to by default, but isn't in a standard place in terms of using it for applications outside the IDE. Then again I doubt this guess too because why the hell would they do that? I'm really not sure what to do here, so I guess I'm looking for some possible explanations for would could be doing this or a solution, if anyone has one... Basically all you need to know about the project properties are that I have opengl32.lib and glu32.lib as the only additional dependencies that I explicitly declare. It also links a bunch of windows libs on its own. Everything else is pretty much default.

Okay, never mind my problem. It involves code. I don't know why it works in the IDE and crashes outside it, really baffles me, but there's a line of code that if I comment it out (it's a call to one of my own classes) it works again. Very strange.

Does VC++ 05 compensate for certain problems or something within the IDE?

Quote:Original post by OrangyTang
Uh, posting the code in question might be helpful. And describing exactly how it differs from normal operation (log files are your friend).

Off the top of my head the only differences between running in VS and out is that the working directory might be different (depending on how you've got your project setup and where you're running the exe from that it).

Didn't post the code because I took care of it, but here's what happened. The problem was an uninitialized variable. I had a for loop that ran through an array of values and called functions from them, but the array was empty so the for loop should have skipped it. Unfortunately the variable for the size of the array was unitialized so garbage was in it instead of 0 and it ran the functions and crashed (since they didn't exist).

What the Visual C++ IDE apparently did was see that the variable was uninitialized and, instead of telling me, corrected the problem behind the scenes and ran the program flawlessly so that I didn't know there was a problem at all.

Real helpful those IDE's are sometimes.

Quote:Original post by BrknPhoenix
What the Visual C++ IDE apparently did was see that the variable was uninitialized

That's not quite correct -- the program heap just ends up initialized differently (usually to a debugging fill pattern such as 0xCCCCCCCC), the objects on top of that remain uninitialized. For the most part, the differences from within the IDE are to aids debugging and prevent user-land errors. Of course, since this is C++, it's impossible to get such features to work perfectly. That said, you haven't disabled the /RTC (under "Basic Runtime Checks"), have you? For example, the following program actually crashes with an assertion from within the IDE pointing out that an uninitialized variable has been used (instead of just printing out a random value, although as you might suspect, the debugger shows said value to be 0xCCCCCCCC):



Of course, it warned me at compile time too. We may be able to point out what it was that your compiler WAS doing, but no, Visual Studio isn't intentionally trying to hide misbehavior in your program from you when debugging it in an IDE. C++ is just short-bus-special enough to be impossible to do this kind of thing correctly 100% of the time with. C++ compilers can't even always agree on what a legitimate program is supposed to do.