«

I have a program that opens a text file, reads data in (using
exclusively ifstream::get(), ifstream:eek(), 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

On 26 mar, 20:30, "drmario" <drma...@cox.net> wrote:
> I have a program that opens a text file, reads data in (using
> exclusively ifstream::get(), ifstream:eek(),
> 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