<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 12, 2014 at 4:16 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=":5xq" class="a3s" style="overflow:hidden">Okay, but that's still causing std::string heap allocations.<br></div></blockquote><div><br></div><div>Ok, all of the discussion thus far has focused exclusively on preventing bugs, so that was where I focused my suggestion.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5xq" class="a3s" style="overflow:hidden">
<br>
With my approach I can do:<br>
<br>
  typedef SmallStringBuilder<128> StringBuilder;<br></div></blockquote><div><br></div><div>You can also achieve the same results with my suggestion... Nothing I suggested is *really* tied to the std::string-composing variant of the raw_*_ostream helpers...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5xq" class="a3s" style="overflow:hidden">
<br>
That turns a whole lot of allocations and strlens across the board into no-ops with a simple centralised change (patch attached, based on Yaron Keren's suggestion). This really *does* make an impact and there are secondary benefits to consider like reduced fragmentation (though I don't have figures, it's clearly going to help). Stack allocation always wins for small strings outside of recursion scenarios.<br>
</div></blockquote><div><br></div><div>You don't have to teach me this. ;] I've spent a decent time turning heap allocations into stack allocations throughout Clang and LLVM.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":5xq" class="a3s" style="overflow:hidden">And the patch also enforces clean storage reset() which is a really tricky operation to do manually with an ostream (requires sequential flush, storage reset, and sync -- do we really expect people to hand-write that without bugs?)<br>
</div></blockquote><div><br></div><div>This is certainly a handy operation. Why not add it to the existing stream classes? It seems useful regardless of whether you want internal or external storage.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":5xq" class="a3s" style="overflow:hidden">
<br>
And it'll be visible to further PGO optimisations (anything that tunes a SmallString will apply here too).<br></div></blockquote><div><br></div><div>I don't know what this means... I don't think that my suggestion is in any way different from the perspective of PGO....</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5xq" class="a3s" style="overflow:hidden">
<br>
On the other hand the approach you suggested just adds some syntactic sugar, at the cost of tying the code closer to std::string heap storage -- exactly what I'm incrementally working to avoid.<br></div></blockquote>
<div><br></div><div>Again, I'm moderately sure you can achieve all the non-std::string storage you want with my suggestion. What I'm suggesting is a general technique for embedding storage inside of a stream object in a way that can easily be used with the existing APIs. It should be generalizable to whatever stream objects are useful to embed storage within....</div>
</div></div></div>