Introduce StringBuilder utility around raw_string_ostream

Chandler Carruth chandlerc at google.com
Thu Jun 12 06:26:59 PDT 2014


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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140612/596c6ff4/attachment.html>


More information about the llvm-commits mailing list