Howard Hinnant wrote:

> There has been no discussion in making high_mark directly observable.
> I'm concerned that deriving from basic_stringbuf in its current form may
> be fragile.  Other state is also not observable (such as openmode).

I'll agree that it is fragile.  I needed an iostream, where the
stringstream interface would have been suitable except that:

  - seekp(0, ios::beg) should not be an error, even when the buffer is
empty,
and

  - seekp beyond the current high_mark should implicitly grow the
buffer (this behavior is consistent with many file systems).

As I recall, openmode was not an issue (since only the derived class
gets to call the base class's constructor, I believe openmode is
"observable" to the derived class).

I was able to implement this using private derivation from stringbuf
(hiding non-const str()), but an accessible high_mark would have made
things much easier.  For various other reasons I didn't end up using
the stringbuf-derived implementation.  I derived directly from
streambuf.  The most pertinent reason (for csc++) is that I needed to
guarantee that growth would not take quadratic time, and stringbuf does
not make that guarantee.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1125063579.895583.53480@z14g2000cwz.googlegroups.com>,
 wade@stoner.com wrote:

> Howard Hinnant wrote:
>
> > There has been no discussion in making high_mark directly observable.
> > I'm concerned that deriving from basic_stringbuf in its current form may
> > be fragile.  Other state is also not observable (such as openmode).
>
> I'll agree that it is fragile.  I needed an iostream, where the
> stringstream interface would have been suitable except that:
>
>   - seekp(0, ios::beg) should not be an error, even when the buffer is
> empty,

I think we fixed this one... oh here it is:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453

That one irritated me too (I guess it irritated a lot of people).

> and
>
>   - seekp beyond the current high_mark should implicitly grow the
> buffer (this behavior is consistent with many file systems).

Would this have still been desirable if you could count on a geometric
buffer (epptr()) growth?  Or were your reasons for other than efficiency?

> As I recall, openmode was not an issue (since only the derived class
> gets to call the base class's constructor, I believe openmode is
> "observable" to the derived class).
>
> I was able to implement this using private derivation from stringbuf
> (hiding non-const str()), but an accessible high_mark would have made
> things much easier.  For various other reasons I didn't end up using
> the stringbuf-derived implementation.  I derived directly from
> streambuf.  The most pertinent reason (for csc++) is that I needed to
> guarantee that growth would not take quadratic time, and stringbuf does
> not make that guarantee.

<nod> It used to require it! :-\

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Howard Hinnant wrote:
> >   - seekp beyond the current high_mark should implicitly grow the
> > buffer (this behavior is consistent with many file systems).
>
> Would this have still been desirable if you could count on a geometric
> buffer (epptr()) growth?  Or were your reasons for other than efficiency?

The existing client code (which previously wrote only to a binary file)
would sometimes do this.  It would "allocate" a dynamic object within
the file (perhaps a vector) and write the current contents (based on
size(), but not on capacity()).  There would be an unwritten "hole"
before the next object was allocated and written.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <pan.2005.08.16.13.01.36.651289@private.com>,
 private@private.com (Garrett Kajmowicz) wrote:

> I'm trying to figure out what the proper output is for the following code,
> according the the standard.  I have two outputs at the end.  I'd also like
> information as to what parts of the standard have an impact on the output.
>
> #include <iostream>
> #include <sstream>
>
> std::stringstream a;
> std::string s;
>
> a.str("Testing data");
> s = "";
> a << 2.5 << " ";
> a >> s;
> std::cout << "Read out: " << "'" << s << "'" << std::endl;
> a >> s
> std::cout << "Read out: " << "'" << s << "'" << std::endl;
> std::cout << "Current buffer value: " << a.str() << std::endl;
>
>
> /////////////////////////////////////////////////
> Sample output #1
> Read out: '2.5'
> Read out: 'ing'
> Current buffer value: 2.5 ing data
>
> ////////////////////////////////////////////////
> Sample output #2
> Read out: 'Testing'
> Read out: 'data2.5'
> Current buffer value: Testing data2.5
>
> ////////////////////////////////////////////////
>
> Can you please specify which is the correct operation, and where
> this specification is defined in the standard.

The intended standard output for your program is #1.  Section 27.7.1.1 /
27.7.1.2 are supposed to clearly indicate this fact.  However they
really don't (imho).  LWG 432 (
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432 )
addresses this and currently has WP status, meaning it has been applied
to the working paper for C++0X (full committee has voted for this
resolution).  This resolution also introduces an extension for C++0X
which will give you output #2 if that is what you require:

std::stringstream a(std::ios::ate | std::ios::in | std::ios::out);

Your implementation may already implement these recommendations.

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Howard Hinnant wrote:
> In article <pan.2005.08.16.13.01.36.651289@private.com>,
> LWG 432 (
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432 )
> addresses this and currently has WP status, meaning it has been applied
> to the working paper for C++0X (full committee has voted for this
> resolution).

Has there been any discussion of making what LWG 432 calls high_mark
observable?  You can currently get it by calling str(), but that takes
O(N) time.

If a derived class wants to find high_mark in O(1) time, it currently
must prevent its clients from calling str(basic_string), and must also
override the seek* members, and keep a redundant data member.  With all
of that, it still needs to call str() after setbuf() (since the
setbuf() behavior is implementation defined).

Even if it does everything in the previous paragraph, it could still
fail if the basic_stringbuf implementation ever calls str(basic_string).

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1124719600.446936.141840@g14g2000cwa.googlegroups.com>,
 wade@stoner.com wrote:

> Howard Hinnant wrote:
> > In article <pan.2005.08.16.13.01.36.651289@private.com>,
> > LWG 432 (
> > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432 )
> > addresses this and currently has WP status, meaning it has been applied
> > to the working paper for C++0X (full committee has voted for this
> > resolution).
>
> Has there been any discussion of making what LWG 432 calls high_mark
> observable?  You can currently get it by calling str(), but that takes
> O(N) time.
>
> If a derived class wants to find high_mark in O(1) time, it currently
> must prevent its clients from calling str(basic_string), and must also
> override the seek* members, and keep a redundant data member.  With all
> of that, it still needs to call str() after setbuf() (since the
> setbuf() behavior is implementation defined).
>
> Even if it does everything in the previous paragraph, it could still
> fail if the basic_stringbuf implementation ever calls str(basic_string).

There has been no discussion in making high_mark directly observable.
I'm concerned that deriving from basic_stringbuf in its current form may
be fragile.  Other state is also not observable (such as openmode).

-Howard

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I'm trying to figure out what the proper output is for the following code,
according the the standard.  I have two outputs at the end.  I'd also like
information as to what parts of the standard have an impact on the output.

#include <iostream>
#include <sstream>

std::stringstream a;
std::string s;

a.str("Testing data");
s = "";
a << 2.5 << " ";
a >> s;
std::cout << "Read out: " << "'" << s << "'" << std::endl;
a >> s
std::cout << "Read out: " << "'" << s << "'" << std::endl;
std::cout << "Current buffer value: " << a.str() << std::endl;


/////////////////////////////////////////////////
Sample output #1
Read out: '2.5'
Read out: 'ing'
Current buffer value: 2.5 ing data

////////////////////////////////////////////////
Sample output #2
Read out: 'Testing'
Read out: 'data2.5'
Current buffer value: Testing data2.5

////////////////////////////////////////////////

Can you please specify which is the correct operation, and where
this specification is defined in the standard.

Thank you.


-     Garrett

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]