A simple problem

[wonder87]

Hello!As a newbie programmer I don't know how to freeze my command line output,when I execute a C program,in order to see the output.Output opens and closes very fast.The trick I know from Pascal to put a 'Readln' statement as a last line doesn't work(with a 'scanf' or something like that.Could anybody give me a clue about that?Thanks in advance.

[TkTkorrovi]

This was the most frequently asked question once in dev-c++ forum, and i'm the most sure this topic has already been discussed many times in this forum as well. Maybe the shortest answer, use only fgets for input, this is the only right function for input, as it restricts the number of input characters, and it would always input the newline as well. Then you can easily use getchar to prevent program from ending. But if you still want to use some weird input methods, like cin, then you have to put fflush (stdin); before getchar.

[Aia]

A common way of pausing the program is to make use of the standard function getchar().

scanf() behaviour will mess up your ability to pause the program with getchar() sometimes. Read about it here.

[Aia]

But if you still want to use some weird input methods, like cin, then you have to put fflush (stdin); before getchar.

Best way is to avoid any `weird input methods' and do not start even
using fflush( stdin ) at all. Here is why not to use it.

[TkTkorrovi]

Yes that's right, effect of fflush is undefined for stdin and it of course must not be used. But if they already do things insecurely, then they must use other uncertain things to compensate it, nothing to do, their choice. Then i say again that these who read would better remember, use only fgets for input. And if you use anything else for input, then delete all rubbish and use only fgets for input.

[Narue]

>Yes that's right, effect of fflush is undefined for stdin and it of course must not be used.
Then why did you tell the OP to use it?

>But if they already do things insecurely, then they must use other uncertain things to compensate it
There are better ways to discard pending characters than to introduce undefined behavior. The easiest is a simple loop:

void jsw_flush ( void ) 
{ 
  int ch;

  do 
    ch = getchar(); 
  while ( ch != EOF && ch != '\n' ); 

  clearerr ( stdin );
}

If you can't suggest one of the better options, you're better off sticking to the original advice of always using fgets.

[TkTkorrovi]

Thanks Narue, discarding pending characters is indeed better than fflush (stdin). I never use fflush (stdin), and thus tend to forget what standard says about it. This discarding pending characters until newline or eof is good when using fgets as well, because fgets doesn't do that. fgets isn't perfect input method, but the only way not to do it character by character. And for not doing anything character by character, the only option is to have the number of input characters large enough, so that the user couldn't likely write too many characters by mistake. I usually use FILENAME_MAX as size, this is 256 or so, and a defined constant, so not a magic number. But, when the user still manages to write too many characters before newline, then the next input would consume it, and would most likely cause a wrong input. The standard doesn't guarantee either, that the input stream would be flushed when the program exits, though mostly it will be flushed.

[Narue]

>I usually use FILENAME_MAX as size
I prefer BUFSIZ, personally.

>then the next input would consume it, and would most likely cause a wrong input.
That's a quality of implementation issue. You write your code so that it can intelligently handle excessively long lines.

>The standard doesn't guarantee either, that the input
>stream would be flushed when the program exits
I'm not sure where you're going this.

[TkTkorrovi]

> I prefer BUFSIZ, personally.

Yep, matter of taste, just because i must use FILENAME_MAX for file names, i prefer to use the same constant everywhere.

> That's a quality of implementation issue. You write your code so that it can intelligently handle excessively long lines.

Yes and this can only be done character by character, at least you have to consume pending characters that way. I talked about input which is not done character by character, using only fgets, which is not exactly a quality implementation, but just a somewhat satisfactory option.

> I'm not sure where you're going this.

??

[TkTkorrovi]

I also use FILENAME_MAX because it used to be somewhat smaller that BUFSIZ, in Linux, BUFSIZ used to be some 8000, and FILENAME_MAX some 4000, it's smaller, but quite enough so that it is quite difficult to type in so many characters. FILENAME_MAX is somewhat related to the size of the command line, as it has to allow a long file name which still has to be shorter than the maximum command line, while BUFSIZ is not exactly for such purpose, it's likely bigger in the systems with more resources.

[dr4g]

You can also use system("PAUSE"), DevC++ puts this in for you automatically, i'm not sure about linux at all since i don't need to use it on Linux :)

It just outputs "Press Any Key To Continue..." and waits for input.

It's not good resourcefully if you use this method, something like getchar() would be a little more light-weight.

If you're using C, getchar() is good.
If you're using C++ cin.get() is good.

Cheers.

[WaltP]

You can also use system("PAUSE"),

NO!!! Here's why

DevC++ puts this in for you automatically,

Only if you don't correct the template, which IMAO everyone should do.

i'm not sure about linux at all since i don't need to use it on Linux :)

And here's one major reason why you don't use it!

[dr4g]

I repeat.. " It's not good resourcefully if you use this method"..

[Aia]

I repeat.. " It's not good resourcefully if you use this method"..

I repeat... what Mr. WaltP said: "NO!!! Here's why"

[iamthwee]

>NO!!! Here's why

No. Most people who do this are just beginners. It is often important for them to get it working with minimal effort so they can concentrate on learning to program.

When the time is right they can learn about it's pitfalls. Even using cin.get() etc is plagued with gotchas, because clearing the input stream is not that straight-forward.

Of course if you ain't a newbie, and you've planning to release your code into the public domain, you should strive to adopt good habits which ensure maximum portability on different platforms and various compilers.

[Aia]

>NO!!! Here's why

No. Most people who do this are just beginners. It is often important for them to get it working with minimal effort so they can concentrate on learning to program.

I respectfully disagree. It's that understanding sympathy for `working with minimal effort' that gets us in trouble as beginners. In the name of `just for beginners' we get burried into a pile of worthless practices hard to break later on. If you are committed to learn to program in C, work hard and learn it right from the beginning.

[iamthwee]

>In the name of `just for beginners' we get burried into a pile of worthless practices hard to break later on.

We are not talking about you. You are specially challenged, learning new habits will be difficult for you. Everyone else learns good habits in time.

Learning to pause the console window is not vitally important for newbies to grasp. Re-read my original post for an explanation.

[Aia]

>In the name of `just for beginners' we get burried into a pile of worthless practices hard to break later on.

We are not talking about you. You are specially challenged, learning new habits will be difficult for you. Everyone else learns good habits in time.

I always give you the benefit of the doubt. However uncalled comments like this does remove all doubts about your character.

Learning to pause the console window is not vitally important for newbies to grasp. Re-read my original post for an explanation.

I don't need to re-read your original post. I already gave the OP the answer of how he could pause the program without the need to use any none portable nor compiler dependent function.