Introduce StringBuilder utility around raw_string_ostream

[Alp Toker]

On 12/06/2014 15:56, Rafael Espíndola wrote:
> 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);

The buffering avoids a virtual dispatch for each call (potentially each 
character) because raw_ostream is a virtual interface that gets passed 
into streamers which don't know which subclass is in use.

(I experimented disabling buffering with raw_null_ostream() and even 
then the buffering helps avoid lots of calls to the no-op virtual 
write_impl() function. So it looks like a good design to me.)

Alp.


>
>
> 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
>>

-- 
http://www.nuanti.com
the browser experts