Re: [RFC] Default constructed stringbufs and stringstreams

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Wed, Sep 29, 2004 at 01:52:06AM +0200, Paolo Carlini wrote:
> I'm working on these ideas related to the short-string optimization
> and just noticed 27.7.1.1/2, about basic_stringbuf default
> constructor: "The function allocates no array object".
> 
> This has interesting implications, since our basic_stringbuf has a
> basic_string *data member*!
> 
> Our current implementation *seems* ok, since, thanks to the empty
> string optimiz we are not allocating anything, but implies, for
> instance, that in the seeks we check that capacity != 0 (i.e., we
> don't look at the pointers, see below) and we cannot tell a default
> constructed stringbuf from one constructed from an empty basic_string.
> 
> If/when we have a short-string inside the string object, a default
> constructed string will acquire a non-zero capacity, the
> implementation of basic_stringbuf will be still possible, in
> principle, since, again, we don't allocate anything.
> 
> Now one of my (many) doubts: due to 27.7.1.1/2 shouldn't a default
> constructed stringbuf have null get/put area pointers? In our current
> implementation this is not happening and I believe we have a bug. This
> seems confirmed by 27.7.1.1/1 which says that the base class is
> initialized by basic_streambuf() (27.5.2.1)
> 
> And there are also interesting implications for DR 453.

I believe that the design of stringbuf is under review for the next
standard.  Probably the requirement that it be in an unusable state
upon creation will be relaxed.

We shouldn't worry too much about odd corners of stringbuf.

Nathan Myers
ncm-nospam@cantrip.org