Introduce StringBuilder utility around raw_string_ostream

Chandler Carruth chandlerc at
Thu Jun 12 08:58:58 PDT 2014

On Thu, Jun 12, 2014 at 4:52 PM, Alp Toker <alp at> wrote:
> The existing stream classes are really light append-only non-seekable
> streams. reset() is a higher-level feature that makes onerous assumptions
> about storage, both "what it can do" and "what we're allowed to do with it".
> So to put reset() or seeking operations inside the primitive ostream
> subclasses would be quite a layering violation.

I dunno. raw_string_ostream has a 'str' method that returns a std::string
reference. I don't know what we could possibly do to this class that would
more tightly couple it to the underlying storage. ;]

But I'm not asking you to add this functionality, just saying that if this
is a problem in practice there seems to be an easy solution.

> I can't see how that'd be done without making a muddle of the ostream
> primitive classes. Adding optional storage to a "simple adaptor class"
> strikes me as a poor idea because it'd no longer be usable be a thin
> interface that's easily inheritable.

I don't see why raw_string_ostream is a thin interface or is easily
inheritable. I think it probably should be declared as final. It is a very
specific, concrete wrapper around a std::string and a raw_ostream. Same
goes for the svector variant.

> At 25 LoC the proposed implementation is still pretty tight even after
> adding the stack allocation facility. And it doesn't hack up ostream
> classes, and fixes various points of use, all clear pluses to me.

We disagree here, restating things seems unlikely to progress anything.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the llvm-commits mailing list