<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 12, 2014 at 1:31 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":62q" class="a3s" style="overflow:hidden">Okay, but that's aiming for a hypothetical LLVM project where developers are paying attention to things like string storage. And that they're aiming not only for correctness, but successfully choosing efficient backing to avoid heap allocations. </div>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":62q" class="a3s" style="overflow:hidden">
<br>
In reality, there are a bunch of developers trying to write various compiler backends, frontends and analyses. Their patches get peer reviewed by people who history has shown don't care about the intricacies of stack string allocation.<br>
</div></blockquote><div><br></div><div>Your view and experience with the LLVM project differs from mine, I have seen the reverse of what you describe.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":62q" class="a3s" style="overflow:hidden">
<br>
The enforced safety in this patch comes without any cost,</div></blockquote><div><br></div><div>Having yet another way to build up a string using a streaming interface is a cost.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":62q" class="a3s" style="overflow:hidden"><div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
, and remove the misuses of flush when we find them (either through an audit or in code review). Now, if there are simple ways to make the interfaces of the stream classes better so that this is easier to get right and harder to get wrong, I'm all for that.<br>

</blockquote>
<br></div>
Simpler? The proposed interface is 13 lines of code :-)<br>
<br>
I'm pretty sure a lot of people will appreciate this. It's just too easy to access the string when it's sitting around in an inconsistent state accessible to the caller, and it's a fact that review didn't catch the errors found in-tree.</div>
</blockquote><div><br></div><div>How many such bugs are in the tree right now? That might be a compelling data point for arguing that we need this.</div><div><br></div><div>If lots of people show up on the review thread saying they strongly prefer the approach of yet-another-stream interface which embeds storage rather than wrapping external storage (because this is a stream interface, not a builder, and the stream interface already has a '.str()' method), then great. But my judgement is that we don't need this, we need more care when using raw_string_ostream.</div>
</div></div></div>