Introduce StringBuilder utility around raw_string_ostream

[Chandler Carruth]

On Thu, Jun 12, 2014 at 8:26 PM, Alp Toker <alp at nuanti.com> wrote:

>
> On 12/06/2014 21:31, Chandler Carruth wrote:
>
>
>> On Thu, Jun 12, 2014 at 5:21 PM, James Molloy <james at jamesmolloy.co.uk
>> <mailto:james at jamesmolloy.co.uk>> wrote:
>>
>>     FWIW, I like Alp's suggestion. There are a bunch of ways to do
>>     string building in LLVM (Twine, raw_string_ostream,
>>     std::stringstream). I'd appreciate a single mechanism for making
>>     strings.
>>
>>
>> But that's not what we would get.
>>
>
> I think you're taking an extreme and isolated view on this one Chandler.


Dave independently wrote almost the exact same thing.


> What James describes is exactly what we get from the proposed patch.
>

We disagree here.


> I've gone ahead and produced examples of invalid string access, and
> demonstrated how the patch fixes each of these:
>

Yes, two bugs in debugging code. Both of which would also be avoided by the
simpler suggestion I already made. I continue to believe the simpler
suggestion could be made to work equally well with stack based storage.


>  , and it's going to be quite far from replacing the use cases of Twine.
>>
>
> The latest iteration of the patch is actually a very worthwhile Twine
> alternative if you're hitting string lifetime issues with that.
>
> Anyway, shouldn't we be working to make the LLVM interfaces safer and more
> efficient for developers?
>

We are. Part of that is code review. Currently, I don't see any strong
consensus that your proposal is the right tradeoff, and an alternative has
been proposed in code review that hasn't really been explored. I'm not sure
what more you want, but I don't think that this thread is a basis for
"moving forward" at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140612/93013b15/attachment.html>