1

I want to read some numbers from the standard input, process them, then read the next bunch of numbers.

I came up with the solution to read the EOF character in a char and clear the eofbit, failbit, and badbit. The following code works on Ubuntu 14.04 with GCC 4.9.2:

#include <iostream>
#include <vector>

int main() {
    std::vector<double> a;
    std::vector<double>::iterator it;
    double x;
    while(std::cin >> x) {
        a.push_back(x);
    }
    std::cout << "First bunch of numbers:" << std::endl;
    for (it = a.begin(); it != a.end(); ++it) {
        std::cout << *it << std::endl;
    }

    // get crap out of buffer
    char s;
    std::cin >> s;
    std::cin.clear();

    // go for it again
    while (std::cin >> x) {
        a.push_back(x);
    }
    std::cout << "All the numbers:" << std::endl;
    for (it = a.begin(); it != a.end(); ++it) {
        std::cout << *it << std::endl;
    }

    return 0;
}

So, on Ubuntu I can type 1<Return>2<Return>^D, get some output, type 3<Return>4<Return>^D, get more output and the program terminates.

On Mac OS 10.10 however, using the same GCC version, the program will not accept the second round of input but outputs the first sequence of numbers twice after hitting ^D the first time.

  • Why is there inconsistent behavior? Is it possible to work around it?
  • What would be the idiomatic way to accept input twice?
  • In my use case, the first bunch of number may eventually be read from a file or pipeline. How can I ask for additional input interactively also in that scenario.
Jonas Greitemann
  • 1,011
  • 10
  • 25
  • Maybe try calling `std::cin.clear()` before using it after sending `EOF` the first time? – Galik Apr 21 '16 at 09:46
  • This is console behaviour, not C++ code. In MacOS it is probably closes input stream after sending EOF [like in Windows](http://stackoverflow.com/questions/10147996/resume-reading-from-iostreamcin-after-ctrlz-eof-ignore-doesnt-work?rq=1) – Revolver_Ocelot Apr 21 '16 at 09:47

1 Answers1

-1

im not all that familiar but, this guy has a similar question: Signal EOF in mac osx terminal

By default, OS X (formerly Mac OS X) terminals recognize EOF when control-D is pressed at the beginning of a line.

In detail, the actual operation is that, when control-D is pressed, all bytes in the terminal’s input buffer are sent to the running process using the terminal. At the start of a line, no bytes are in the buffer, so the process is told there are zero bytes available, and this acts as an EOF indicator.

This procedure doubles as a method of delivering input to the process before the end of a line: The user may type some characters and press control-D, and the characters will be sent to the process immediately, without the usual wait for enter/return to be pressed. After this “send all buffered bytes immediately” operation is performed, no bytes are left in the buffer. So, when control-D is pressed a second time, it is the same as the beginning of a line (no bytes are sent, and the process is given zero bytes), and it acts like an EOF.

You can learn more about terminal behavior by using the command “man 4 tty” in Terminal. The default line discipline is termios. You can learn more about the termios line discipline by using the command “man termios”.

Accepted Answer from Eric Postpischil

I dont have OSX to test against, but maybe this explains the behaviour

Community
  • 1
  • 1
Git
  • 214
  • 5
  • 16