Introduce StringBuilder utility around raw_string_ostream

[Chandler Carruth]

On Thu, Jun 12, 2014 at 1:31 PM, Alp Toker <alp at nuanti.com> wrote:

> Okay, but that's aiming for a hypothetical LLVM project where developers
> are paying attention to things like string storage. And that they're aiming
> not only for correctness, but successfully choosing efficient backing to
> avoid heap allocations.
>

> In reality, there are a bunch of developers trying to write various
> compiler backends, frontends and analyses. Their patches get peer reviewed
> by people who history has shown don't care about the intricacies of stack
> string allocation.
>

Your view and experience with the LLVM project differs from mine, I have
seen the reverse of what you describe.


> The enforced safety in this patch comes without any cost,
>

Having yet another way to build up a string using a streaming interface is
a cost.


>  , and remove the misuses of flush when we find them (either through an
>> audit or in code review). Now, if there are simple ways to make the
>> interfaces of the stream classes better so that this is easier to get right
>> and harder to get wrong, I'm all for that.
>>
>
> Simpler? The proposed interface is 13 lines of code :-)
>
> I'm pretty sure a lot of people will appreciate this. It's just too easy
> to access the string when it's sitting around in an inconsistent state
> accessible to the caller, and it's a fact that review didn't catch the
> errors found in-tree.
>

How many such bugs are in the tree right now? That might be a compelling
data point for arguing that we need this.

If lots of people show up on the review thread saying they strongly prefer
the approach of yet-another-stream interface which embeds storage rather
than wrapping external storage (because this is a stream interface, not a
builder, and the stream interface already has a '.str()' method), then
great. But my judgement is that we don't need this, we need more care when
using raw_string_ostream.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140612/ddf2d5f1/attachment.html>