I am working on the final part of the first stage of a game I'm making on Windows. I am planning on transferring it over to the Mac, but I was hoping to get the first stage working properly before doing so; to that end, I ask for you help here, and I apologize in advance for any Windows specific code that might be posted here
I'm using the IDE DevC++ from Bloodshed Software. I believe that it works both on Mac and on Windows (if this is the case, then I can post the project files along with the source). When I commpile my program and run it, I run into major problems. I have two DLL files that I have made, and each contains a class header file along with the definition for that class. When I run the program, the window is generated and then instantly closed. I don't even have time to see what is being drawn (I'm using OpenGL with just a bit of the Windows API). Oddly enough, when I run it in debug mode inside of my IDE, it doesn't detect any SIGSEV or other memory error
Adding to the strangness is the fact that if I do a step-by-step of the code with the help of the debugger, I can get to the line when I initialize one of my DLLs (which contains a DLL itself).
This line of code works fine (inside the code I am using the offsetX, offsetY, and offsetZ variables that I explain below), the screen is generated, and drawing occurs (the drawing is partially taken care of inside the two DLL files). When I exit the step-by-step mode of the debugger and continue to run the program, it runs perfectly normally. Objects are drawn to the screen, I can move the screen around, minimize/maximize the screen. I can even close the screen without getting an error message of any kind.
Before posting, I tried to debug the code on my own. Inside of one of my header files, I have the code:
and inside the constructor, I have the lines of code
When I compile the program and run it (not inside the IDE), it opens the screen and then immediately closes it, but when I run it inside of the IDE, it works perfectly fine (I don't even have to use the stepping function provided by the debugger.
If I take away the
inide of the constructor and just leave the code
then the program runs perfectly both inside of and outside of the IDE (no debugger mode required to make it run).
I am really confused by this, and I really have no clue as to what is causing it. I can post code if you want, but there is quite a lot of it, and some of it is quite Windows specific.
Thanks in advance for any help
-wyrmmage

why anyone posts a Windows DLL question in the "Carbon" forum completely eludes me...

The problem itself is likely a problem of the debugger automatically initializing memory that isn't initialized outside the debugger. That said, you give next to no actual information we can use. And if what you're working on has DLLs and pieces of the Win32 API, then it most definitely won't work on the Mac...

I posted in this forum because I was hoping that my problem was not related to Windows/DLL specific issues; besides, the forum is titled Carbon/C++ and I am programming in C++

Thanks for the help, I'll look through my program for invalid memory commands I was hoping to use GLUT to initialize a window and an OpenGL context for me on the Mac (That's what I'm using the Windows API to do) and to use bundles instead of DLLs (OneSadCookie informed me that they were close to the same and tha tI shouldn't have too much trouble going from DLLs to bundles and from bundles to DLLs).
Thanks for the help, I'll try and post here to tell you if it solves the problem
-wyrmmage

I'd recommend just using SDL on both sides for the windowing etc. GLUT is really lacking in many areas, especially with event handling. The only thing I don't like about SDL's event handling would be the limitation of mouse buttons, but then manymouse has been brought to my attention, and has solved that problem.

From what I was suggesting, it isn't so much invalid memory operations, but memory you're expecting to be initialized (usually 0 initialized), but is actually whatever there was in memory beforehand. Debuggers often 0-initialize memory you allocate (either on the stack or the heap) for you, which hide bugs that show up when you build a release version that doesn't do that. The only memory that's guaranteed to be 0-initialized are global and static variables.

oh, ok...that's good to know (I've had this problem at different points in time and had to re-write some sections of code, looks like I might not have to do that next time I have this happen )
Turns out the problem was that I was accessing private variables directly (would that be considered a memory violation, or what? )...easy fix, once I found it
Thanks for all the help guys ^_^
-wyrmmage

Quote:Turns out the problem was that I was accessing private variables directly

:-o
The compiler should stop you from doing that...

yes, it should.....
I'm not really sure why it didn't stop me from accessing private members of the class, but I think it had to do with the fact that I am passing the pointer of an object called 'object' (that I was accessing private variables on) to another 'object' object from another DLL.
Still not quite sure why the compiler didn't see that, but now it is fixed
-wyrmmage