streambuffs and their associated buffers

D

drmario

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
 
J

James Kanze

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
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).
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top