This is the mail archive of the
mailing list for the libstdc++ project.
Re: Doubts about in_avail vs showmanyc
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: Nathan Myers <ncm-nospam at cantrip dot org>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 04 Mar 2003 23:55:36 +0100
- Subject: Re: Doubts about in_avail vs showmanyc
- References: <3E650DC8.email@example.com> <20030304222558.GA1267@tofu.dreamhost.com>
Nathan Myers wrote:
On Tue, Mar 04, 2003 at 09:34:16PM +0100, Paolo Carlini wrote:Thanks anyway, another possible mistake avoided!
Hi Nathan, hi everyone
on second tought I have some doubts about your observations
that showmanyc should return the _sum_ of of whatever is
already in the buffer and what you get using recv/fstat.
I'm sorry to have made another mistake: ::fstat() tells the full
file size, so you would have to subtract the current position
from that, and ignore the count of characters still in the buffer
(unless it is more). But that's not your point...
The descriptions of in_avail and showmanyc are different. The
former is supposed to tell you (quickly!) about what's buffered,Ah, now I see.
if any, where the latter is allowed to do more work and tell
whatever it can learn. It's protected, so it may be called by
derived classes and exposed to users. It is defined in terms of
what behavior can be expected from underflow, which is likewise
(only) protected and might be called with a non-empty buffer.
underflow() must return characters already buffered before it
starts returning newly-read characters or EOF.
In our current implementation this is "hidden" in some code which
put back area (which, in turn, I'm still trying to understand in detail
basing on your
So, the smallestOk.
value showmanyc should return is egptr()-gptr(), but it might
Users can call in_avail() in a loop, and it might be more efficient
if they can read chunks bigger than BUFSIZ.Thanks once again Nathan: I will do my best to put to good use your