Matt Austern <austern@sgi.com> wrote:
>kuehl@wolfurt.informatik.uni-konstanz.de (Dietmar Kuehl) writes:
>> Nathan writes:
>> : in_avail() in this example should return 1.  If it fails to do so,
>> : you have a library bug.
>>
>> I think it is correct that 0 is returned: All standard streams maintain
>> only one joint position for reading and writing.
>
>That's true for basic_filebuf, but I think Nathan is right about
>basic_stringbuf. ...  My interpretation of basic_stringbuf<>::overflow()
>(27.7.1.3, paragraph 5) is that it should not change the position of the
>get pointer.  In my implementation I go to some trouble to make sure
>of that.

Indeed, in the original example the program proceeded to read the
text that had been inserted there, so it is clear that the read
pointer remained at the beginning of the string.

We're looking at a bug not just in where the pointers end up, but in
how the library intereprets the pointers.  If it kept the pointers
together as in filebuf, one could work around the bug by seeking to
the beginning.  I don't know any workaround for the bug demonstrated.
It seems clear that string_buf::in_avail is badly broken in that
implementation of the library.

Nathan Myers
http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Claude Qu=E9zel<claude_quezel@syntell.com> wrote:
>Is it that I don't understand the behaviour of in_avail() (most
>probably) or that both VC++ and CPP Builder libraries are broken?

The latter.

>in_avail() is documented as: If a read position is available, returns
>egptr() - gptr() otherwise returns showmanyc(). I thought that size
>should be non zero in the following example. Is this right or what am
>I missing?
>
>#include <sstream>
>
>int main()
>{
> std::stringstream ss;
> ss << 1;
> int size =3D ss.rdbuf()->in_avail(); // returns 0 (is this OK ?)
> int temp;
> ss >> temp; // reads 1
>}

in_avail() in this example should return 1.  If it fails to do so,
you have a library bug.

--=20
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
Nathan Myers (ncm@nospam.cantrip.org) wrote:
: >#include <sstream>
: >
: >int main()
: >{
: > std::stringstream ss;
: > ss << 1;
: > int size =3D ss.rdbuf()->in_avail(); // returns 0 (is this OK ?)
: > int temp;
: > ss >> temp; // reads 1
: >}

: in_avail() in this example should return 1.  If it fails to do so,
: you have a library bug.

I think it is correct that 0 is returned: All standard streams maintain
only one joint position for reading and writing. After writing one character
into the stream, the write and read positions are pointing to the character
just behind the just inserted character. There is none. Thus, no character
is available for the stream and 'in_avail()' returns 0. To have 'in_avail()'
return 1 it would be necessary to seek back to the beginning of the stream.
--
<mailto:dietmar.kuehl@claas-solutions.de>
<http://www.informatik.uni-konstanz.de/~kuehl/>
I am a realistic optimist - that's why I appear to be slightly pessimistic


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

kuehl@wolfurt.informatik.uni-konstanz.de (Dietmar Kuehl) writes:

> : in_avail() in this example should return 1.  If it fails to do so,
> : you have a library bug.
>
> I think it is correct that 0 is returned: All standard streams maintain
> only one joint position for reading and writing. After writing one character
> into the stream, the write and read positions are pointing to the character
> just behind the just inserted character. There is none. Thus, no character
> is available for the stream and 'in_avail()' returns 0. To have 'in_avail()'
> return 1 it would be necessary to seek back to the beginning of the stream.

That's true for basic_filebuf, but I think Nathan is right about
basic_stringbuf.  There's a lot of text in 27.7.1 that only makes
sense if the read and write positions are separate (see, for example,
the discussion of positioning in Table 90, which explicitly says that
the user can reposition one of the the read and write positions
without changing the other), and I can't find any text to suggest that
basic_stringbuf has a joint read/write position.

My interpretation of basic_stringbuf<>::overflow() (27.7.1.3,
paragraph 5) is that it should not change the position of the get
pointer.  In my implementation I go to some trouble to make sure
of that.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Is it that I don't understand the behaviour of in_avail() (most
probably) or that both VC++ and CPP Builder libraries are broken?
in_avail() is documented as: If a read position is available, returns
egptr() - gptr() otherwise returns showmanyc(). I thought that size
should be non zero in the following example. Is this right or what am
I missing?

#include <sstream>

int main()
{
 std::stringstream ss;

 ss << 1;
 int size = ss.rdbuf()->in_avail(); // returns 0 (is this OK ?)
 int temp;
 ss >> temp; // reads 1

 return 0;
}

Claude
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]