sdm@cs.brown.edu (Scott Meyers) (04/09/91)
From the istream man page:
insp=&ins.putback(c)
Attempts to back up ins.rdbuf(). c must be the
character before ins.rdbuf()'s get pointer.
(Unless other activity is modifying ins.rdbuf()
this is the last character extracted from ins.) If
it is not, the effect is undefined.
Two questions:
1. Why am I limited to putting back the last character I removed?
There is no such limitation for ungetc in the standard C library.
2. Given that I am limited to putting back the last character I
read, why does putback take a parameter?
All illumination appreciated,
Scott
-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."jss@gold.kpc.com (Jerry Schwarz) (04/10/91)
In article <71302@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes: From the istream man page: insp=&ins.putback(c) Attempts to back up ins.rdbuf(). c must be the character before ins.rdbuf()'s get pointer. (Unless other activity is modifying ins.rdbuf() this is the last character extracted from ins.) If it is not, the effect is undefined. This peculiar interface was motivated by a desire to make it easy to derive new streambufs. > 1. Why am I limited to putting back the last character I removed? > There is no such limitation for ungetc in the standard C library. It is possible that you are extracting characters from a readonly data structure. For example a strstreambuf that was initialized with a |const char*|. strstreambuf ignores the argument and just backs up the (internal) pointer. > 2. Given that I am limited to putting back the last character I > read, why does putback take a parameter? Putback was originally specified in a way that corresponded to ungetc. Some streambufs (e.g. filebuf) will use the character and do allow you to putback a character other than the one you extracted most recently. The restriction (that you should only putback the previously extracted character) was added later when I noticed the situation described in case 1. The X3J16 library working group is considering eliminating the argument. That is declaraing istream::putback() to back up the pointer. Jerry Schwarz
mjv@objects.mv.com (Michael J. Vilot) (04/10/91)
>From brunix!sdm >Newsgroups: comp.lang.c++ >Message-ID: <71302@brunix.UUCP> >Organization: Brown University Department of Computer Science > >Two questions: > > 1. Why am I limited to putting back the last character I removed? > There is no such limitation for ungetc in the standard C library. > > 2. Given that I am limited to putting back the last character I > read, why does putback take a parameter? 1. The limitation does indeed exist for C. The ANSI C library definition of ungetc() includes the following caution: "One character putback is guaranteed. If the ungetc function is called too many time on the same stream without an intervening read or file position on that stream, the operation may fail." 2. For much the same reason the ANSI C function takes an argument. This has the virtue (? ;-) of being 'consistent' with what a C programmer would expect, but I agree that the semantic restrictions on pushing back a character tend to make the argument somewhat superfluous. Mike