streambuffs and their associated buffers

Discussion in 'C++' started by drmario, Mar 26, 2008.

  1. drmario

    drmario Guest

    I have a program that opens a text file, reads data in (using
    exclusively ifstream::get(), ifstream::peek(), ifstream::ignore(),
    ifstream::clear(), and ifstream& operator >>), crunch some #s, output data,
    close the file.

    Is there a function I can use to directly access the buffer associated with
    the streambuff of my ifstream object?

    I'm getting input failure and I can't figure out why. So I wanna go to
    the step directly before the failure, and then say "show me everything
    currently in the input buffer". I know, I know I can fix this by just
    changing my algorithm. I don't want to. I want to know why what I'm doing
    isn't working, and fix it. Then I'll change it :) If you like Windows
    more than UNIX you may be asking yourself "Why the hell would you wanna know
    that, instead of just changing it?" lol.

    Thanks in advance,
    Mario
     
    drmario, Mar 26, 2008
    #1
    1. Advertising

  2. drmario

    James Kanze Guest

    On 26 mar, 20:30, "drmario" <> wrote:
    > I have a program that opens a text file, reads data in (using
    > exclusively ifstream::get(), ifstream::peek(),
    > ifstream::ignore(), ifstream::clear(), and ifstream& operator
    > >>), crunch some #s, output data, close the file.


    > Is there a function I can use to directly access the buffer
    > associated with the streambuff of my ifstream object?


    Try rdbuf(). It should return a pointer to the streambuf object
    (or the filebuf object, if you call it on an ifstream, rather
    than just on an istream).

    > I'm getting input failure and I can't figure out why. So I
    > wanna go to the step directly before the failure, and then say
    > "show me everything currently in the input buffer".


    Input failure isn't necessarily from the streambuf. It can be a
    result of a error in the input format, for example. And...
    regretfully, even getting at the filebuf won't provide you any
    information. (A flaw in the standard I/O, IMHO.)

    For starters, even before worrying about that level: Check the
    status after every input, and as soon as you fail, check eofbit,
    i.e.:

    source >> something ;
    if ( ! source ) {
    if ( source.bad() ) {
    // You've got a better implementation than most:
    // there was a hard error somewhere. (On a Unix
    // system, try outputting errno here. Might work
    // on Windows as well, for that matter.)
    } else if ( source.eof() ) {
    // This generally means that the filebuf reported
    // an error (or EOF).
    } else {
    // The input wasn't formatted correctly for what
    // you were trying to read.
    }
    }

    Once you've isolated the exact input which failed, try "peek"ing
    at the input before the statement, to determine where you are in
    the stream.

    If all else fails: see
    http://kanze.james.neuf.fr/articles/fltrsbf1.html, and use the
    information there to write a filtering streambuf which traces
    the exact bytes you return (to the istream). But it's more work
    than should be necessary.

    > I know, I know I can fix this by just changing my algorithm.
    > I don't want to. I want to know why what I'm doing isn't
    > working, and fix it. Then I'll change it :)


    I definitly approve of trying to understand why something isn't
    working before trying to fix it. Otherwise, the new code is
    likely to have the same errors (maybe positionned a little
    differently, so they don't show up immediately in your tests).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Mar 26, 2008
    #2
    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. Mike
    Replies:
    4
    Views:
    5,114
    Kevin McMurtrie
    Aug 3, 2004
  2. Replies:
    3
    Views:
    284
  3. kelvSYC
    Replies:
    2
    Views:
    436
    kelvSYC
    Mar 10, 2006
  4. Brendan
    Replies:
    1
    Views:
    663
    Gabriel Genellina
    Dec 16, 2008
  5. Carl Banks

    ctypes and buffers

    Carl Banks, Sep 19, 2010, in forum: Python
    Replies:
    2
    Views:
    435
    Carl Banks
    Sep 19, 2010
Loading...

Share This Page