difference between running .exe and compiler running .exe???

This is a discussion on difference between running .exe and compiler running .exe??? within the C++ Programming forums, part of the General Programming Boards category; I just recently changed my linked list over to a queue in my project since the linked list was having ...

  1. #1
    Registered User
    Join Date
    Mar 2007
    Posts
    416

    difference between running .exe and compiler running .exe???

    I just recently changed my linked list over to a queue in my project since the linked list was having issues ending when at the end of the list. The queue works great, sort of, since I can get the size of the queue and stop the function once the size is reached. However, here is my problem. I can compile the program and it will run without any problems, and exactly as it i want it too. Then when I run the .exe file by clicking it the window comes up with "the program has encountered a problem and needs to close" message. So what are the differences between running it through the compiler/IDE vs. running it without the compiler? The part I changed is below. I should probably also note this is opengl, but the problem isn't opengl specific. If I render one object I can click the .exe and run it without the compiler and not have trouble. When I render more than one that's when I have troubles.

    Code:
    //head is the name of the queue, it is a private member of the class LOADOBJ
    
    bool LOADOBJ::RenderAllObjects()
    {
        if(head.size() == 0) return false; //nothing to render
        ObjectList *temp; //temp space for the render function
        int f_index = 0, f_index2 = 0; //face index, and non-changing face index
    
        /*render all objects to the screen*/
        glPolygonMode( GL_BACK, GL_LINE ); // draw back face with lines
        glPolygonMode( GL_FRONT, GL_LINE ); // draw front face with lines
    
        for(int n = 1; n <= head.size(); n++){
            temp = head.front(); //get the front object
            head.pop(); //pop the front object
            head.push(temp); //then put it back in line for the next time it's rendered
            for(int i = 0; i < temp->face_count; i++){
    
                //determine what type needs to be rendered
                if(temp->vert_per_face[i] == 4)
                    glBegin(GL_QUADS); //render squares
                else if(temp->vert_per_face[i] == 3)
                    glBegin(GL_TRIANGLES); //render triangles
                else if(temp->vert_per_face[i] == 2)
                    glBegin(GL_LINES); //render lines
                else if(temp->vert_per_face[i] == 1)
                    glBegin(GL_POINTS); //render points
                else
                    glBegin(GL_POLYGON); //if nothing else render a polygon (5 or more vertex)
    
                f_index2 = f_index;
                for(int n = f_index2; n < f_index2 + temp->vert_per_face[i]; n++){
                    //create the 3D vertex
                    glVertex3f(temp->v_x[ temp->fv[n]-1 ], //x coordinate
                               temp->v_y[ temp->fv[n]-1 ], //y coordinate
                               temp->v_z[ temp->fv[n]-1 ]); //z coordinate
                    f_index++;
                }
                glEnd();
            } //end for loop
            f_index2 = 0; f_index = 0;
        }
        return true;
    }

  2. #2
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,594
    A "compiler" cannot run an exe.
    It is possible, however, to attach a debugger to a running application.
    There is also the difference in work directory when running from the IDE and not.

    All I can say, is that you seem to have some sort of undefined behavior somewhere.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Ex scientia vera
    Join Date
    Sep 2007
    Posts
    478
    There shouldn't really be a difference, except that it might be using a dll, which, when run by the compiler in the working directory it uses, is available to the program, and when you double click it, it isn't. Or something in that general direction.

    Try sticking it in a debugger. Also, I highly recommend you trash dev-cpp and Code::Blocks and use Visual Studio express. VS' debugger is superb, and dev-cpp hasn't been updated for over three years and uses an old version of the MinGW compiler by default.
    "What's up, Doc?"
    "'Up' is a relative concept. It has no intrinsic value."

  4. #4
    Registered User
    Join Date
    Mar 2007
    Posts
    416
    Ok this is weird. When I run through the debugger the program loads and runs, but does not render anything to the screen. If I compile and run it runs like I want/it should. Clicking .exe file still gives the error. What kind of undefined behavior is common with queues? As you can see in the render function I don't see anything anywhere, and if it was truly undefined why would it work when I compiled and ran it?

    Also, i don't use Dev-cpp, my signature is kind of old. I use codeblocks 8.02, and have tried VS express. It was nice but I like codeblocks.

  5. #5
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,594
    I don't know. Undefined is undefined, that's why it's called undefined.
    If you just let it run through the debugger, will it crash then? If so, the debugger will point out where the crash occurs.
    Visual Studio also has a JIT feature, which should allow you to launch the debugger if a program crashes outside it. It helps to pinpoint the problem.

    First step in debugging is always find out what is causing the problem.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Registered User
    Join Date
    Mar 2007
    Posts
    416
    No it does not crash through the debugger. That's what I thought was weird. I will go through everything in more detail and see what I find. I haven't come across something like this before where it runs through the IDE but not outside the IDE. If I have more questions I will post them. Thanks so far!

  7. #7
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,594
    If you can't use the JIT debugger, then you can try to match working directory. For example, change the current directory to a hard coded directory at start and see if you get a crash in the debugger and without it.
    Sometimes, this is the cause.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    Registered User
    Join Date
    Mar 2007
    Posts
    416
    I don't quite get what you mean by that, or how to do it. Could you give me a small step by step type thing. Doesn't have to be detailed.

  9. #9
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,594
    Like, add:
    Code:
    _chdir("C:\\");
    ...to the beginning of the code and see if it crashes. If it does, then it might be more likely to crash inside the IDE. Maybe.
    Of course, it might be a race condition...

    Another thing to try:
    Add something to halt the program, like a MessageBox or some input in a console app. The attach a debugger to the program and let it run. Hopefully that will allow you to see the crash in the debugger.
    I believe VS Express supports attaching a debugger, or I hope so.
    You'll find it under Tools -> Attach to Process.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Registered User
    Join Date
    Mar 2007
    Posts
    416
    Codeblocks can also attach a debugger. I attached the PID it gave me when I ran the debugger and nothing happened. I also put MessageBox() functions in different places, and it does run through rendering the images, but it hangs on the second object and doesn't finish rendering it. This is another spot that doesn't make sense to me, if it can render the first, why isn't it rendering the second or third or so on? Here's where I added the MessageBoxes. Also, I ran the function through a console window and had it print all the values it stores, and it is storing and adding the second, third, and so on objects correctly.

    Code:
    bool LOADOBJ::RenderAllObjects()
    {
        if(head.size() == 0) return false; //nothing to render
        ObjectList *temp; //temp space for the render function
        int f_index = 0, f_index2 = 0; //face index, and non-changing face index
    
        /*render all objects to the screen*/
        glPolygonMode( GL_BACK, GL_LINE ); // draw back face with lines
        glPolygonMode( GL_FRONT, GL_LINE ); // draw front face with lines
    
        for(int m = 0; m < head.size(); m++){
            //MessageBox(NULL,"test","test",MB_OK); //FIRST MESSAGE BOX
            temp = head.front(); //get the front object
            head.pop(); //pop the front object
            head.push(temp); //then put it back in line for the next time it's rendered
            for(int i = 0; i < temp->face_count; i++){
    
                //determine what type needs to be rendered
                if(temp->vert_per_face[i] == 4)
                    glBegin(GL_QUADS); //render squares
                else if(temp->vert_per_face[i] == 3)
                    glBegin(GL_TRIANGLES); //render triangles
                else if(temp->vert_per_face[i] == 2)
                    glBegin(GL_LINES); //render lines
                else if(temp->vert_per_face[i] == 1)
                    glBegin(GL_POINTS); //render points
                else
                    glBegin(GL_POLYGON); //if nothing else render a polygon (5 or more vertex)
    
                f_index2 = f_index;
                for(int n = f_index2; n < f_index2 + temp->vert_per_face[i]; n++){
                    //create the 3D vertex
                    glVertex3f(temp->v_x[ temp->fv[n]-1 ], //x coordinate
                               temp->v_y[ temp->fv[n]-1 ], //y coordinate
                               temp->v_z[ temp->fv[n]-1 ]); //z coordinate
                    f_index++;
                }
                glEnd();
            } //end for loop
            //MessageBox(NULL,"test2","test2",MB_OK); //SECOND MESSAGE BOX
            f_index2 = 0; f_index = 0;
        }
        return true;
    }

  11. #11
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    i had this problem and it was an uninitialized function pointer.

    i had something like:

    Code:
    if(func)
    {
            func();
    }
    and forgot to initialize func to NULL in the object's constructor, but when i launched the app with the debugger attached, it would change func's default assignment to 0, however otherwise, it was given a nonzero address and the function attempted to execute.

  12. #12
    Registered User
    Join Date
    Mar 2007
    Posts
    416
    oh... my... freakin... word... that was the dumbest mistake. You were right method, I went back and checked where I could have not initialized, or not set something to null. In my structure that holds all the vertex information i have one variable "int face_count" and i incremented it before I initialized it. Well now it works all hunky dory. Thank you guys for all your help.

  13. #13
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,594
    Umm, a thought here, but most compilers actually complain if you try to use an uninitialized variable. Visual Studio's debugger even breaks on the line where such a thing is done.
    The fact that you get no warnings worries me. Or if you did, you must have ignored them.
    Turn up all warnings to maximum.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Registered User
    Join Date
    Mar 2007
    Posts
    416
    Another good point, I reinstalled the compiler and not all warnings were on by default, and I always compiled and ran it, not just compiled so the warnings would disappear from the screen when it ran. I now enabled all warnings, and compile is separately from running it. Thank you.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problems running compiled .exe on other machines.
    By Troels Leth in forum C++ Programming
    Replies: 39
    Last Post: 05-09-2008, 05:30 AM
  2. compiler does run .exe not
    By hoppy in forum C++ Programming
    Replies: 10
    Last Post: 01-06-2008, 01:59 PM
  3. Windows error running outside compiler
    By sunburnbyRA in forum C++ Programming
    Replies: 1
    Last Post: 11-12-2003, 04:14 PM
  4. Help- Problems running outside of compiler
    By Derek5272 in forum C++ Programming
    Replies: 17
    Last Post: 05-07-2003, 08:19 AM
  5. help running a program from compiler
    By jordan6 in forum C++ Programming
    Replies: 2
    Last Post: 03-21-2002, 03:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21