End of file signal

I've started learning c++ recently and am doing it by some tutorials.. anyways, it says that I can send the "end of file" signal by pressing Ctrl+Z, but when I try that I just write ^Z .

here is the part of the code that I'm stuck at since after I write all the numbers I need I just cant send that "end of file" signal to move on:



p.s. using windows XP, Dev-c++ 4.9.9.2 (not that it matters xD)

If you're taking input from the keyboard, just quit when you're through.

In a situation where keyboard input is being redirected to a file, the ctrl-Z (for Windows) is effective at closing the file and ending the redirection.

What do u mean just close the file?
I'm talking about running the prog within Dev-C++ with the F9. It opens in CMD, prog is working well untill i get to that part that i wrote here, and then i cant move on to the rest of the program that uses these numbers i input. I wouldnt say anything but its actually an app from the book and it just says to press ctrl+Z to send the signal when i'm done with inputing all the numbers, to move on with the program :S

edit: i see u edited your answer, but no, thats not the case here

The common reason for using Ctrl-Z from the keyboard is when employing the "poor man's editor", the UNIX/Linux version of which is referenced in my avatar. In MS-DOS, that would be:
copy con file.txt
which copies from stdin (AKA "con" for "console") to file.txt. What it copies is whatever you type -- you will notice that the command-line prompt does not return, but rather it lets you type and type. What it's doing is copying into file.txt everything that you type. Then the way that you tell it to stop copying and to close file.txt is with a Ctrl-Z followed by ENTER.

Open a DOS window (AKA "console", AKA "Command Prompt") and give it a try. That's what we had to do back in the early days of DOS when all you got with the system was EDLIN (which came back in Win2k; wouldn't be surprised to learn it was hiding out in NT all this time) so you had to shell out your own money to buy a third-party editor -- the only thing more painful than typing an entire file from start to finish with no errors was to do it using EDLIN. I think that if you redirect input from a file of EDLIN commands, you can use it in batch mode to automate editting several files; I did the same thing on Linux once using the ed editor.

OK, when you talk of "send[ing] the 'end of file' signal by pressing Ctrl+Z", that's what comes to mind.

You say that it's an app from a book. What does the app's code show about processing the Ctrl-Z? Now, when a control sequence is entered (eg Ctrl-Z), it does display in the format "^Z", but that is just a single character. ^A has an ASCII code of 1, ^B is 2, ^G is 7 (AKA BEL), and ^Z is 26 -- Esc is 27, BTW. It's been quite a while since I've played with it, but I think that when you read a character in, you would test its ASCII code for being within the range of 1 to 27 and interpret it accordingly.

A special case would be an ASCII code of zero, which signals that a special key had been pressed (eg, arrow key, navigation key, function key F1 through F12) and that the next code needs to be interpreted specially to determine which special key it was. In my The Programmer's PC Sourcebook (1991), page 1-22, these are referred to as "IBM Keyboard Extended Function Keys", so Google'ing on variations of that term might yield useful results. For example, 0-72 is an up arrow, 0-80 is a down arrow, and 0-75 is a left arrow, but 0-115 is a Ctrl-left arrow and 0-155 is an Alt-left arrow.

Hope that points you in the general direction you want to be heading.

Let's presume that x, count, and sum are all integers. They certainly appear to be such.

Your loop will continue to run so long as you enter information that can be converted by cin to an integer. Once you enter something else, cin will fail. It will continue to fail thereafter until you take action to heal it.

You need to do two things. One, you need to always check your input methods for success. Failing to do so is the sign of a newbie or a schlock.

Two, you need to write code to terminate your loop. If you want to accept input other than integers (such as a terminating keystroke), you need to write it differently. If you want to detect a failure and exit on that, then you need to do that.

See cin.good (), cin.fail (), cin.bad (), cin.eof (), etc.

See also the other methods for using cin. Those would be get (), getline (...), et. al.

Ok well, I already mentioned that I actually AM a newbie. So I'm not really sure what u mean by always check your input methods for success, a bit better explanation or an example would be more then nice :P,

anyways, as for nr. 2, i havent been doin with the fail/bad/eof cin-s yet tho i'll get on it asap.

I do need to terminate that loop yes, but the thing that bothers me is that the book / actual code written by some "pro" explains no further then "press ctrl+z or ctrl+d for linux when ure done inputing the numbers", so i wrote the good code and been hitting my head with the keyboard for like an hour trying to figure out wtf is wrong :S

Your "pro" was mimicking the shell (for certain shells). If you want to mimic the shell, then you'll need to write code that does that.

As to the input thing, here's one example. The extraction operator (>>) asks two things of cin (and cousins): 1) get some input, 2) convert it to the type of variable that I have designated for the input. Operation 2 may very well fail. "AXz" cannot be converted to an integer (at least not in any default base). Cin therefore fails. It won't work until you repair it. You may wind up crashed, or in an infinite loop, or any number of other things.

Read about the functions you use and write your code appropriately. The functions can't guarantee to work. Most of them guarantee to work or tell you that they failed. Ask them.

OK, I'm still confused about what your situation is. You're trying to write code and yet you keep talking about "some 'pro'" having written the code.

I'll assume for the moment that the code is not yet written and that you are trying to write it. What you already posted

is reading in character input that represent an integer (I assume) value and converts that string into its corresponding integer value.

I assume that you need to detect when the user has entered a Ctrl-Z. As I mentioned, I'm pretty sure that a Ctrl-Z would be a character input that has an ASCII value of 26. So at the same time that you're streaming in integer values you need to be testing for a Ctrl-Z character.

Maybe cin's peek() method might help; from http://www.cplusplus.com/reference/...tream/peek.html:


If you are actually trying to do something different than I'm assuming, then please explain. Eg, what is that "actual code" that that pro had written?


PS
Since Ctrl-Z is end-of-file (EOF) in Windows/DOS text files (I would assume that stdin is a text file), then there should be some merit in investigating cin.eof() as sizablegrin had suggested.

Eg, http://www.cs.utk.edu/~cs102/lectures/cinLecture.html (pertinent text about half-way down the page; do a Find on eof. The discussion of cin.fail() would also help you to understand what he was trying to tell you.

Presuming integers, your cin won't survive reading a ctrl-Z, even though that value qualifies, independently, as a small integer value.

Asking cin to parse and convert to an integer requires it to accept input only so long as the characters are '0' through '9', a sign character, or characters representing exponential notation (unless you've specified a base other than 10).

You would be better off conditioning your loop on "true." Then, after input, check for success. If you've succeeded, then and only then use your value. If you've failed, get out of the loop. Once out, determine whether that failure represents an EOF, another form of "fail", or a "bad."

This would put one extra statement in your loop. It's the kind of statement that will get you hired rather than passed over.

It would not be good to condition your while on cin.good (). That would cause you to exit, yes, but AFTER you have used invalid data in your accumulation.

Read about cin. Analyze the problem as presented to you. Proceed accordingly. Quite frankly, you've not presented us with enough information. I'm judging types on the way you're using them, and intent by what you have posted.

Realize that what might constitute a EOF for cin is platform-dependent. Scattered clues are leading me to presume that it's Intel/Windows, but you shouldn't force us to depend on inferences based on scattered clues.

Ctrl-Z followed by enter should do it.

...presuming that you're on Windows, and haven't set the global file mode to binary...