Introduce StringBuilder utility around raw_string_ostream

[Chandler Carruth]

On Thu, Jun 12, 2014 at 4:52 PM, Alp Toker <alp at nuanti.com> 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: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140612/0a6669b8/attachment.html>