🚀 go-pugleaf

In article <199603010214.VAA16273@pleiades.cs.rpi.edu>
axl@zedat.fu-berlin.de (Axel Thimm) writes:

|> I have had a look in the April draft, but I think that there is a small
|> ambiguity about eof() methods in streams.
|> Is the eof-flag raised, when the end of the stream is reached, or when
|> an attempt to move past this end is made?

Yes.

I've not reverified the exact words in the latest draft, but in previous
versions, it was undefined exactly when the EOF flag would be set.  For
this reason, the eof() function is, in fact, practically useless.
(IMHO, of course.)  On the other hand, even if it were well defined, it
would probably not be as useful as one would like, for reasons explained
below. 

|> I think the most common
|> practice is the latter, but the ANSI draft uses the former statement.

The common practice is that the implementation will sometimes do one,
sometimes the other.  For example:

    char                str[]( "12" ) ;
    istrstream          s( str ) ;
    int                 i ;
    s >> i ;
    //  s.eof() is generally true in most implementations

But:

    char                str[]( "12x" ) ;
    istrstream          s( str ) ;
    int                 i ;
    char                c ;
    s >> i >> c ;
    //  s.eof() is generally false in most implementations

Note that although the results of s.eof() are different, the position of
the read mark relative to the end of file is exactly the same in both
cases: the last read succeeded, but the next one will fail.

|> Declaring the end of a stream as the first charachter _after_ the last
|> character of the stream would rescue the expression, but wouldn't fit
|> into a concept of an end. (Usually one thinks of an end as belonging to
|> the whole)
|> As I am rather convinced, that the eof is raised at an attempt to meove
|> past the end, I'd like to ask how to check this in a binary file without
|> having to perform a movement.

You might want to try the function `peek'.  I tend to use this function
a lot.  Basically, this forces a look-ahead, which will set the eof if
there is nothing more there.

Historically, C has generally used the eof condition to indicate that
the last read failed (because of eof); other languages (at least,
Pascal), have used it to indicate that the next read will fail.  From a
programming point of view, the latter is more useful, but impossible to
implement correctly for formatting input.  Consider the following:

    char                str[]( "    " ) ;
    istrstream          s( str ) ;

If the next operation on s is operator>>( istream& , int& ), the
operation will fail (because of end of file), and so a predictive eof()
should return true.  If the next operation is get(), however, it will
succeed, so a predictive eof() should return false.

The solution is to test for failure (fail()) after conversion, when
using formatted input.  For character-wise input (either binary or not),
you have the choice: test for failure after, or use peek to test for eof
before.  Once failure has been detected, you may use eof() to determine
if this was the reason for the failure.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]