Really quick question on how to keep the cmd window from force closing...

[nelledawg]

Hey guys, this is a really basic question but I can't figure out how to answer it! I wrote a program for users to input product price, quantity, etc. After getting the input the program displays the quantity, price, total cost, etc., and asks if the user wants to input another product. If they press "Y" it is supposed to loop back to the beginning (all works fine), and if they press "N" the program is supposed to display the final totals of ALL products inputted. It does all of this, but the only problem is when I debug the program and enter "N", the window closes immediately! I know I can press Ctrl+F5 to run without debugging, and when I do that the table displays just like it is supposed to. However, I need to know how to make the window stay open like that when it is being debugged or else I will lose points! Please someone help!

[nelledawg]

Ok well, I did a little research and duh, forgot about system("pause") AND getch()!

Which would be more acceptable to use?

[Nick Evan]

Ok well, I did a little research and duh, forgot about system("pause") AND getch()!
Which would be more acceptable to use?

I would strongly suggest that you use neither.
- getch() is only supported by the Turbo compiler (as far as I know anyway)
- system("pause") won't work on a linux/mac/bsp/etc computer

getchar() is the function you're looking for:

int main()
{
  printf("hello");
  getchar();
  return 0;
}

[Radical Edward]

> Which would be more acceptable to use?
It depends on a few things. The most obvious is that neither getch() nor system("pause") work everywhere.

getch():

1. Isn't mandated by the C standard, so you can't assume it's available.

system("pause"):

1. Requires that an external program called pause exists.
2. The external program isn't under your control and could be malicious or not do what you want.

Only system("pause") is a complete solution--assuming you're using Windows' pause program--because it pauses, prompts the user, and handles the keypress management. getch() is really just notification of a keypress, so your code has to handle the prompt.

If you want something that works everywhere, there's more to think about because the C standard doesn't mandate the kind of raw input that lets you check for an immediate keypress like with getch(). The standard input functions require that you press enter before your program even knows that input it available, and by then you could have any number of characters. If there are any characters in the stream then getchar() won't pause the program at all, and on top of proving a prompt you have to clear the stream of excess characters:

#include <stdio.h>

void flush_line(FILE *is)
{
  int ch;

  do
    ch = fgetc(is);
  while (ch != '\n' && ch != EOF);
}

void pause_program(const char *message, int flush)
{
  if (message != NULL)
    fputs(message, stdout);

  if (flush)
    flush_line(stdin);

  (void)getchar();
}

There's still one problem with that solution: it requires the programmer to know if there are expected excess characters in the stream. If pause_program is called with flush as true and there aren't excess characters, flush_line will also pause the program and that will cause two pauses instead of one. If pause_program is called with flush as false and there are excess characters, pause_program won't pause at all.

You can test how it works different ways with this driver:

int main()
{
  getchar();
  pause_program("Press [Enter] to continue . . .", true);
  return 0;
}

If you think that's a lot of work and a lot to think about, Edward agrees. The best solution is not to get into this situation at all. :) Run your programs directly from a command prompt and the lifetime of the window won't be related to the lifetime of your program. If you still want to run from your IDE or by clicking the application's icon, just pick whatever you're most comfortable with and ignore the people who tell you you're wrong. ;)

But keep in mind that as you learn more about programming and become more paranoid--as programmers tend to--what your comfortable with will change. Always keep an open mind and re-evaluate your assumptions as you go. That's what makes a good programmer. :)