[v3] PR 10975

[Nathan Myers]

On Tue, Jan 06, 2004 at 08:34:40PM -0500, Jerry Quinn wrote:
> Paolo Carlini writes:
>  > Ok, now I see: basically, from the implementation point of view, the body of
>  > basic_stringbuf::seekoff() doesn't need to be protected from capacity() 
>  > == 0,
>  > because it's already able to deal with that case: seeking to pos_type(0)
>  > succeeds, seeking to pos_type(0) automatically fails, as should be. And in
>  > this way we are consistent with basic_filebuf. Good.
>  > 
>  > Now, one remaining doubt: what about basic_stringbuf::seekpos? Shouldn't we
>  > remove the check on _M_string.capacity() from there too?
> 
> Actually, my patch fixes seekpos as well :-)

Good, sort of...

> Given that stringstreams don't provide a direct interface ala open()
> to explicitly set the buffer string after construction would be an
> argument to me that stringstreams should always be considered open.
> 
> And given that the standard is ambiguous about it at the moment, why
> not push towards a more sensible solution?

I guess the point is that the standard is not so ambiguous as I had
thought at first.  It really does enshrine "not-open" modes.  Can I
imagine a real program that breaks because of our simpler semantics?
No.  But I can easily imagine a conformance test suite complaining.

I won't argue against applying your patch, but it should be commented
as implementing semantics that the LWG probably will not ratify.
I can imagine the extensions group accepting a comprehensive proposal
to simplify stringstream semantics and effectively eliminate the 
"not-open" modes, but I cannot afford to promote such a proposal.

Nathan Myers
ncm-nospam@cantrip.org