cin, getline, delimiter, buffer and... confusion

Discussion in 'C++' started by bgeneto, Apr 7, 2005.

  1. bgeneto

    bgeneto Guest

    Hi!

    Please consider the following C++ code fragment: (using <iostream> and
    <string> standard libraries)

    string s; int i;
    cin >> i;
    getline (cin, s);

    Correct me if I'm wrong: In this first case cin reads data from the
    input buffer until it finds a delimiter, leaving the delimiter
    (newline) in the input (keyboard) buffer. After that, the getline
    function reads that delimiter directly from the input buffer, thus
    ending the input process, without asking for another string data.
    Right? Now consider this code

    string s; int i;
    cin >> i;
    cin >> s;

    Again, the first cin reads data until it finds the delimiter, leaving
    the delimiter in the input buffer. So, why the second cin requires new
    data from the user if it finds the delimiter in the buffer?

    Exactly in what aspect cin behave different from getline()?

    Thanks in advance,

    Bernhard Georg Enders.
     
    bgeneto, Apr 7, 2005
    #1
    1. Advertising

  2. On Thu, 6 Apr 2005, bgeneto wrote:

    > Hi!
    >
    > Please consider the following C++ code fragment: (using <iostream> and
    > <string> standard libraries)
    >
    > string s; int i;
    > cin >> i;
    > getline (cin, s);
    >
    > Correct me if I'm wrong: In this first case cin reads data from the
    > input buffer until it finds a delimiter, leaving the delimiter
    > (newline) in the input (keyboard) buffer. After that, the getline
    > function reads that delimiter directly from the input buffer, thus
    > ending the input process, without asking for another string data.
    > Right? Now consider this code
    >
    > string s; int i;
    > cin >> i;
    > cin >> s;
    >
    > Again, the first cin reads data until it finds the delimiter, leaving
    > the delimiter in the input buffer. So, why the second cin requires new
    > data from the user if it finds the delimiter in the buffer?
    >
    > Exactly in what aspect cin behave different from getline()?
    >
    > Thanks in advance,
    >
    > Bernhard Georg Enders.



    While cin does leave a '\n' in the stream, it doesn't actually use it for
    anything when you call cin again. getline(), on the other hand, sees the
    newline character as regular input and finishes reading.

    Reidar
     
    =?ISO-8859-1?Q?Reidar_=D8ksnevad?=, Apr 7, 2005
    #2
    1. Advertising

  3. bgeneto

    bgeneto Guest

    If the newline character ends a cin input, why "it doesn't actually use
    it for anything when you call cin again"? For me it seems that cin
    flushes the buffer before actually reading anything from there. Thanks,

    Bernhard.

    Reidar ├śksnevad wrote:
    > On Thu, 6 Apr 2005, bgeneto wrote:
    >
    > > Hi!
    > >
    > > Please consider the following C++ code fragment: (using <iostream>

    and
    > > <string> standard libraries)
    > >
    > > string s; int i;
    > > cin >> i;
    > > getline (cin, s);
    > >
    > > Correct me if I'm wrong: In this first case cin reads data from the
    > > input buffer until it finds a delimiter, leaving the delimiter
    > > (newline) in the input (keyboard) buffer. After that, the getline
    > > function reads that delimiter directly from the input buffer, thus
    > > ending the input process, without asking for another string data.
    > > Right? Now consider this code
    > >
    > > string s; int i;
    > > cin >> i;
    > > cin >> s;
    > >
    > > Again, the first cin reads data until it finds the delimiter,

    leaving
    > > the delimiter in the input buffer. So, why the second cin requires

    new
    > > data from the user if it finds the delimiter in the buffer?
    > >
    > > Exactly in what aspect cin behave different from getline()?
    > >
    > > Thanks in advance,
    > >
    > > Bernhard Georg Enders.

    >
    >
    > While cin does leave a '\n' in the stream, it doesn't actually use it

    for
    > anything when you call cin again. getline(), on the other hand, sees

    the
    > newline character as regular input and finishes reading.
    >
    > Reidar
     
    bgeneto, Apr 7, 2005
    #3
  4. bgeneto wrote:
    >
    > If the newline character ends a cin input, why "it doesn't actually use
    > it for anything when you call cin again"?


    Because it is not the only way why an input may be declared as beeing
    ended and the program might want to figure out, if that last input
    has already reached the end of the input line or not.

    --
    Karl Heinz Buchegger
     
    Karl Heinz Buchegger, Apr 7, 2005
    #4
  5. bgeneto

    Jon Bell Guest

    In article <>,
    bgeneto <> wrote:
    >
    > string s; int i;
    > cin >> i;
    > cin >> s;
    >
    >Again, the first cin reads data until it finds the delimiter, leaving
    >the delimiter in the input buffer. So, why the second cin requires new
    >data from the user if it finds the delimiter in the buffer?
    >
    >Exactly in what aspect cin behave different from getline()?


    First, the behavior you describe is caused by the '>>' (stream extraction)
    operator, not by cin. So your question should be, "in what respect does
    '>>' behave different from getline()?"

    The answer is that by design, '>>' skips any leading whitespace (blanks,
    tabs and newlines) that it finds at the current input position, and does
    not actually start reading data until it encounters a non-whitespace
    character. getline() does not skip leading whitespace.

    --
    Jon Bell <> Presbyterian College
    Dept. of Physics and Computer Science Clinton, South Carolina USA
     
    Jon Bell, Apr 7, 2005
    #5
  6. bgeneto

    Evan Guest

    > For me it seems that cin flushes the buffer before
    > actually reading anything from there. Thanks,


    It's not flushing it, it just (as Jon said) ignores leading whitespace.
    To convince youself of this, try the following code:

    cout << "Input a number: ";
    cin >> a;
    cout << "Input another number: ";
    cin >> b;
    cout << "You said " << a << " and " << b << endl;

    and when prompted the first time enter "4 5<enter>" (no quotes of
    course). It will display the second prompt but won't wait for input,
    then it will say you've typed 4 and 5. Here's the progression if you do
    that:

    1. Before the first cin, assume the input stream is empty.
    2. You put "4 5\n" into the input stream
    3. The first stream extraction (line 2) reads the 4 from the stream,
    but leaves the following space. After this line, the input stream
    contains " 4\n".
    4. The second cin skips over the leading space and reads 5. It leaves
    the trailing newline in the stream. After this line the stream contains
    "\n".

    You can see this somewhat in action by adding the following line after
    the cin statements:

    cout << "First character in stream: \'" <<
    static_cast<char>(cin.peek()) << "\'\n";

    This prints out the first character that is left in the stream. You
    will be able to see that the first such message prints that the
    character is ' ' and the second is '
    ' (of course meaning a newline). If you remove the static_casts you'll
    see the ASCII code.
     
    Evan, Apr 7, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Schumacher

    Getline delimiter

    Chris Schumacher, Nov 13, 2003, in forum: C++
    Replies:
    2
    Views:
    720
    Rolf Magnus
    Nov 14, 2003
  2. Alex Vinokur
    Replies:
    3
    Views:
    3,610
    Alex Vinokur
    Feb 2, 2005
  3. Chris Coleman

    getline() and a '\0' as a delimiter

    Chris Coleman, Mar 4, 2005, in forum: C++
    Replies:
    1
    Views:
    402
    Chris Coleman
    Mar 5, 2005
  4. Aleander

    cin and cin.getline()

    Aleander, Mar 6, 2005, in forum: C++
    Replies:
    5
    Views:
    8,711
    Alex Vinokur
    Mar 6, 2005
  5. Replies:
    1
    Views:
    436
    Juha Nieminen
    May 17, 2008
Loading...

Share This Page