Introduce StringBuilder utility around raw_string_ostream

[David Blaikie]

On Thu, Jun 12, 2014 at 6:26 AM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Thu, Jun 12, 2014 at 2:19 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> > 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.)
>>
>> I see.
>>
>> Do you know how many of these calls could be avoided by implementing
>> operotor<< in the derived class too? I.E, how often do we known that
>> we are streaming to a string?
>>
>> Having forgot to add some calls to flush myself in the past I agree
>> that it would be nice to have some API that lets us avoid that. If
>> that can be done efficiently in the common case with an external
>> buffer, that is better.
>
>
> The really tricky thing is to have a non-virtual size-adjusting operation
> that the base raw_ostream can use to indicate how large things are. In
> addition to that, you'd also want std::string to expose the ability to do
> uninitialized resizing, but we could at least teach SmallString to allow
> that. But I don't know how to capture the size into a variant underlying
> type as-you-go in any efficient way.

FWIW SmallString has this, inherited from SmallVector (see
SmallVector::set_size) - though I'm mucking about with seeing if I can
prototype replacing SmallVector with an alias template to std::vector
to see if it's worth keeping SmallVector (and thus fixing a bug or two
I've found it in that'll require some restructuring/careful handling
during growth), which means getting rid of this support. In this
particular regard I'm hoping the avoided memset of using set_size
isn't actually important for performance.

- David

>
> Honestly, I would be more interested in something which provided more
> debugging tools when flush fails to be called. That would also help all of
> the users of the stream interface that *need* the stream interface. And
> while I too have made this mistake, it just isn't that common (mostly
> because writing code using streams isn't that common).
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>