Introduce StringBuilder utility around raw_string_ostream

[Rafael Espíndola]

Probably a silly question, buy why does the stream class need a
secondary buffer when writing to a std::string?

Normally it is buffered because we don't want to call write for every
call to <<, but std::string's internal buffer should be fairly
efficient.

With an unbuffered specialization we could use

  std::string buf;
  raw_string_ostream os(buf);
  ...
  // no flush
  use(buf);


On 12 June 2014 08:42, Chandler Carruth <chandlerc at google.com> wrote:
>
> 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.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>