🚀 go-pugleaf

In article <4hgap6$6o7@fu-berlin.de> axl@zedat.fu-berlin.de (Axel
Thimm) writes:

|> kanze@gabi-soft.fr (J. Kanze) wrote:

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

|> But I think that you can use this only with text streams, not with
|> binary streams (You would not be able to tell a eof-char from an
|> ordinary binary char).

The functions istream::peek() and istream::get() return an int, not a
char.  Exactly what this int is supposed to contain when the read
succeeds is not particularly clear from the draft, but I would suppose
that the intent is for the results to be basically the same as that of
fgetc in C: either the char read, cast to unsigned char, then to char,
or EOF (which must be negative).

Thus, in implementations where sizeof( int ) > sizeof( unsigned char),
you shouldn't have any problems.  In the rare case where sizeof( int )
== sizeof( unsigned char ), this isn't the only problem: there will be
unsigned char's whose value doesn't fit in an int, and the mapping of
them to the int is implementation defined.  (An implementation could,
for example, map them all to 0.)

Since this is comp.STD.c++, I should really talk about what the draft
standard says.  In the draft standard, of course, there is no EOF,
only a function `ios_traits::eof()'.  At present, all that is
guaranteed is that this function returns ``an int_type value which
represents the end-of-file.''  At present, there is nothing (except
market pressure and common sense, neither of which have anything to do
with the standard) to prevent an implementation from defining 'a' as
eof.  A simple solution would be to require that this value not be
representable in a ios_traits::char_type.  While this might be
difficult for an implementation in which all integral types are the
same size, I'd rather they had the difficulty than me.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]