2995. basic_stringbuf default constructor forbids it from using SSO capacity

Section: 30.8.2.1 [stringbuf.cons] Status: New Submitter: Jonathan Wakely Opened: 2017-07-07 Last modified: 2017-07-12

Priority: 3

View other active issues in [stringbuf.cons].

View all other issues in [stringbuf.cons].

View all issues with New status.

Discussion:

[stringbuf.cons] says that the default constructor initializes the base class as basic_streambuf() which means the all the pointers to the input and output sequences (pbase, eback etc) are all required to be null.

This means that a stringbuf that is implemented in terms of a Small String Optimised std::basic_string cannot make us of the string's initial capacity, and so cannot avoid a call to the overflow virtual function even for small writes. In other words, the following assertions must pass:

#include <sstream>
#include <cassert>

bool overflowed = false;

struct SB : std::stringbuf
{
  int overflow(int c) {
    assert( pbase() == nullptr );
    overflowed = true;
    return std::stringbuf::overflow(c);
  }
};

int main()
{
  SB sb;
  sb.sputc('1');
  assert(overflowed);
}

This is an unnecessary pessimisation. Implementations should be allowed to use the SSO buffer immediately and write to it without calling overflow. Libc++ already does this, so is non-conforming.

[2017-07 Toronto Tuesday PM issue prioritization]

Priority 3; is this affected by Peter Sommerlad's paper P0407R1?

Proposed resolution:

This wording is relative to N4659.

  1. Edit 30.8.2.1 [stringbuf.cons] as indicated:

    explicit basic_stringbuf(
      ios_base::openmode which = ios_base::in | ios_base::out);
    

    -1- Effects: Constructs an object of class basic_stringbuf, initializing the base class with basic_streambuf() (30.6.3.1 [streambuf.cons]), and initializing mode with which. It is implementation-defined whether the sequence pointers (eback(), gptr(), egptr(), pbase(), pptr(), epptr()) are initialized to null pointers.

    -2- Postconditions: str() == "".