Running executable problem.

[Danger Manger]

I'm new to programming, and i've encountered a weird problem. I'm trying to run a simple c++ program, but command prompt would close soon as it finishes running the program. It closes immediately after running that I can't see the results. How can I keep the command prompt screen from closing?

 

[Lord of Shadows]

You open command prompt manually and run the executable like with every other console based program. --Where do people get this impression that a program is suppose to stay open after closing?

Edit: Sorry if I came off harsh, I die a little inside everytime I see system("pause");

 

[Danger Manger]

Ok, that fixed it. Thanks.

 

[nameless_centurian]

You open command prompt manually and run the executable like with every other console based program. --Where do people get this impression that a program is suppose to stay open after closing?

Edit: Sorry if I came off harsh, I die a little inside everytime I see system("pause");

i don't mind the system call, but it does make me worry if i copy the source code to another platform and i get some sort of invalid system call at the end of the program.

are there any other reasons you dislike system("pause"); ?

 

[MadJuggla9]

i don't mind the system call, but it does make me worry if i copy the source code to another platform and i get some sort of invalid system call at the end of the program.

are there any other reasons you dislike system("pause"); ?

Thats the only thing it does do, it pauses the terminal screen in windows. It has a gain and a loss, works in windows, doesn't elsewhere; unless you have some interpreter before the executable is output.

 

[mikeblas]

are there any other reasons you dislike system("pause"); ?

The call to system() causes a large dependency and increases the size of the generated code. For homework assignments, I guess it's not much of a concern, but I don't think it's ever too early to try and learn about the side efects of using routines from libraries arbitrarily.

Copying the code to a different machine is a valid concern. There are workarounds which will mitigate some of these problems, but I never seen them explained by people who suggest using system() to solve this problem. (Ironically, I also see people recommending system() bitching about not returning int from main(), and other trivialities.)

The right way to solve this problem, if you ask me, is to learn how to use the debugger. Putting a breakpoint at the end of main() (or after the loop that prints the output you want to see, or ...) will pause exeuction without changing the program under test.

 

[MadJuggla9]

The call to system() causes a large dependency and increases the size of the generated code. For homework assignments, I guess it's not much of a concern, but I don't think it's ever too early to try and learn about the side efects of using routines from libraries arbitrarily.

Copying the code to a different machine is a valid concern. There are workarounds which will mitigate some of these problems, but I never seen them explained by people who suggest using system() to solve this problem. (Ironically, I also see people recommending system() bitching about not returning int from main(), and other trivialities.)

The right way to solve this problem, if you ask me, is to learn how to use the debugger. Putting a breakpoint at the end of main() (or after the loop that prints the output you want to see, or ...) will pause exeuction without changing the program under test.

This is somewhat off topic but I figure you might know, is there a specific interrupt to call system pause on windows? One of the assigned low number ints? I don't remember my assembly much but it seems the "press any key to continue" was a windows dependant interrupt backwards compatible with DOS.

 

[mikeblas]

This is somewhat off topic but I figure you might know, is there a specific interrupt to call system pause on windows? One of the assigned low number ints? I don't remember my assembly much but it seems the "press any key to continue" was a windows dependant interrupt backwards compatible with DOS.

There's no interrupt for this in Windows. Interrupts haven't been used as an API invocation mechanism since the demise of 16-bit OSes.

In DOS, there was no Interrupt to do this, either. It would be a combination of two calls to INT 021h; one to show the "Press any key..." message, and the other to wait for a key.