more console closing down

[BluesMatt]

I know that a lot has been written here on this topic. And yes, I am also new. I have written programs before (VB) but have always known what platform and OS my executable would run on so I have never considered portability issues when writing. But I want to get better/smarter so now I am thinking about portability when writing. I am just learning C and so far, I have written code like this:

#include <stdio.h>
int main()
{
	int b;
	printf("Enter a value: ");
	scanf("%d", &b);
	if (b < 0)       //Check for less than zero.
        	printf("The entered value is NEGATIVE.\n\n");
	else if (b == 0) //Check for equal to zero.
		printf("The entered valus is ZERO.\n\n");
			
	else if (b > 0)  //Added this unnecessary check to make the code more readable.
		printf("The entered value is POSITIVE.\n\n");

	printf("Close the window to terminate the program...");
 	do{}while(1);
   
	return 0;
}

I think one of my assumptions is that the "console" is always the screen and that the "console" always displays in a window (that is close-able). But from reading some of the posts, it seems like that assumption might be false. If the "console" isn't the screen, then what device is it?

[Chervil]

Depending on the which operating system etc. the program runs on, the console could be the entire screen, but it could not be closed, any more than a windows program can close the entire screen.

When the program is eventually interrupted, it need not close the screen or window, it could just terminate the program and keep the console open ready for the user to type the next command.

Regarding this solution: do{}while(1); I saw similar code elsewhere just yesterday. It is a bad idea. The while loop is resource-hungry, it is busily consuming CPU cycles going around and round that loop. Imagine you are running the program, and then have to get up to answer the phone. When you get back you find the cooling fans running at full speed to cool the machine.

[BluesMatt]

Thanks for the reply. I definetly agree that the infinite loop eats CPU cycles. Not so certain about the CPU overeating but I get your point.

Honestly, I can't remember the last time I used a computer that was not Windows or Mac (but I'm an end user or a developer for end users and not a sys admin). These computers run programs in closeable windows. But I also know that I know nothing about other systems that don't run programs in closeable windows.

[Duthomhas]

Your program should not care about the console window. It is safe (both in terms of security and of user interaction) to assume that.

On Windows systems, if you run an exe with the "I'm a console program" flag set, Windows will do one of two things:
(1) if your user started the exe from a console window, it will run in that window and terminate, leaving the window as it was.
(2) if your user started the exe any other way (like clicking on it from an Explorer window or in the Start menu), it will spawn a new console window subprocess and attach it to your program's I/O. When your program terminates, the console will disappear.

Modern Unix WMs will behave very much the same. Some older ones may be too stupid to figure things out either
(1) at the start, requiring your user to start an xterm then run your program
(2) at the end, leaving the xterm running after your program has terminated
There is really nothing you can do in your program to fix either of those (minor, even if annoying) problems.

I don't have access to a Mac, but IIUC, it will spawn a console window and destroy it automatically when your program terminates.


The only real issue is those systems that may close your console window before you want it to. That is where things like this come in:
http://www.cplusplus.com/articles/iw6AC542/

The simplest, most cross-platform way would be to just say

int PressEnterToQuit()
  {
  cout << "Press ENTER to end the program." << flush;
  string s;
  getline( s );
  return 0;
  }

int main()
  {
  cout << "Hey, I'm the main() program!\n";

  return PressEnterToQuit();
  }

Hope this helps.