Introduce StringBuilder utility around raw_string_ostream
alp at nuanti.com
Thu Jun 12 12:26:50 PDT 2014
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
> But that's not what we would get.
I think you're taking an extreme and isolated view on this one Chandler.
What James describes is exactly what we get from the proposed patch.
Where you see StringBuilder you get the assurance of safe string
management. Use it as an ostream, and pop out a StringRef with
equivalent lifetime to the object -- simple and efficient.
> As has already been discussed, the proposed interface would not
> replace real use cases for raw_string_ostream
What are your parameters? The proposed patch includes 45 replacements of
real use cases for raw_string_ostream. Each one is a win.
3/4 of those are heap allocation fixes.
Several are real bug fixes for output that's being truncated but isn't
covered by tests. Do you really think we should keep the unsafe
interface and wait for users to report each of these as PRs? (And
there's more broken code in clang, which is what originally set me on
I've gone ahead and produced examples of invalid string access, and
demonstrated how the patch fixes each of these:
> , 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?
I think it'd be best if we stuck to the main issue and addressed any
final review comments going forward. Listening to every viewpoint
doesn't mean we can always satisfy them all.
the browser experts
More information about the llvm-commits