Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!ulysses!kpv
From: kpv@ulysses.att.com (Phong Vo[drew])
Newsgroups: comp.lang.c++
Subject: Re: Problems with putback()
Message-ID: <14861@ulysses.att.com>
Date: 22 May 91 01:40:32 GMT
References: <1991May20.213530.1864@jpl-devvax.jpl.nasa.gov> <739@taumet.com>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 16

In article <739@taumet.com>, steve@taumet.com (Stephen Clamage) writes:
> 
> The documentation for putback says that if the putback character does not
> match the one extracted, the effect is undefined.  The reason for that
> is you might be reading a strstream from read-only storeage.
> ...
This is an example of a bad interface design (sorry jss).
The clause "the effect is undefined" is always a cause for problems
because programmers cannot rely on the interface. If putback() is designed
only to back up one input byte, then it should not require an input argument.
If it is to be as ungetc() in stdio, then it should simply say (as stdio does)
that only one byte can be pushed back regardless of whether or not it matches
the last input byte. I don't know what the equivalence of fseek()/ftell() is
for iostream but an interesting question is where would the logical stream
pointer be after putback().  If the implementation is not careful,
the effect is going to be not-simple-to-define.