Introduce StringBuilder utility around raw_string_ostream

David Blaikie dblaikie at gmail.com
Wed Jun 25 21:53:15 PDT 2014


On Wed, Jun 25, 2014 at 5:52 PM, Alp Toker <alp at nuanti.com> wrote:
>
> On 26/06/2014 03:16, Chandler Carruth wrote:
>
>>
>> On Thu, Jun 26, 2014 at 2:09 AM, Alp Toker <alp at nuanti.com
>> <mailto:alp at nuanti.com>> wrote:
>>
>>     I've made that change, plus a couple more updated uses, and landed
>>     this in r211749.

FWIW, perhaps I wasn't clear - but my "I'd like to loop back around
with Chandler to nail down the design choice" was "I'm not signing off
on this patch without Chandler", so the commit may've been a bit
premature.

>> I don't understand why.

Which I guess was Chandler's understanding too (the "why" being "why
did you commit?", at least that's how I read it).

>> I think my objection to the design direction stands, but I'm tired of
>> arguing pointlessly so I'm not going to restate things.
>
>
> I actually do care about your suggestion Chandler.
>
> It's my understanding that, if we get that alternative scheme to work at
> some point and agree it's an improvement,

I'm not sure why you say this as though there's some unknown about how
to make this scheme work. It's pretty simple to just add another ctor
to your string_ostream class that takes a reference to a string and
uses that just like raw_string_ostream did previously. (& then remove
the duplicate class, one way or the other - presumably in favor of the
existing class rather than the new one). Yeah, it wastes a little
stack when using a user-specified buffer, but that's pretty much
unavoidable.

>  it'll be entirely compatible with
> the important bug fixes and malloc reduction enabled by this commit, which
> is where the value lies.

The reduction in bug-writability is significant, the malloc reduction
I assume is unobservable in any actual performance metric so I'm not
really concerned/worried/interested in that side of it (so much so I
question the need to proliferate the choice of types here further by
providing not just one (where zero might be possible, following
Chandler's preferred direction) but two types)

- David

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



More information about the llvm-commits mailing list