<div dir="ltr">How about an even simpler approach.<div><br></div><div>Put a std::string inside raw_string_ostream, and a default constructor which binds the reference to its internal std::string. I'm moderately confident that our optimizers will remove the "dead" std::string that is left in the class by users that want to leverage external storage.</div>
<div><br></div><div>This has the advantage of not introducing any new types or patterns, merely removing the requirement to pass in a std::string to provide storage by using internal storage.</div><div><br></div><div>That's getting far enough down in the simplicity (for folks learning about the APIs) to make me quite happy.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 12, 2014 at 2:39 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 class=""><br>
On 12/06/2014 14:17, Yaron Keren wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This looks like a very useful class. It should work for the similar SmallString pattern, right?<br>
<br>
  SmallString<256> OutName;<br>
  llvm::raw_svector_ostream Out(OutName);<br>
cast<ItaniumMangleContext>(<u></u>CGM.getCXXABI().<u></u>getMangleContext()).<u></u>mangleCXXVTT(RD, Out);<br>
  Out.flush();<br>
  StringRef Name = OutName.str();<br>
<br>
-><br>
<br>
  StringBuilder Out;<br>
cast<ItaniumMangleContext>(<u></u>CGM.getCXXABI().<u></u>getMangleContext()).<u></u>mangleCXXVTT(RD, Out);<br>
  StringRef Name = Out.str();<br>
</blockquote>
<br></div>
Yeah, that'd work. But for cases like the above we should first provide a SmallString<> backed specialization that permits StringBuilder<256> Out;<br>
<br>
The initial patch I posted is aimed more at the std::string-backed cases. A stack-allocating specialization should follow nicely from that.<br>
<br>
Alp.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yaron<br>
<br>
<br>
<br>
2014-06-12 8:01 GMT+03:00 Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>>:<div><div class="h5"><br>
<br>
<br>
    On 12/06/2014 07:41, David Blaikie wrote:<br>
<br>
        (would find this a little easier to review if it were in Phab)<br>
<br>
        One off-the-cuff thought: If it's not already documented, you<br>
        might<br>
        want to put a comment in raw_string_ostream's ctor that<br>
        declares that<br>
        it /really shouldn't/ touch the string (since you're passing in an<br>
        object in the derived class that won't itself be constructed until<br>
        after the raw_string_ostream's ctor has finished). Or, better<br>
        yet, if<br>
        there's a way to build a raw_string_ostream without a string, then<br>
        attach it later (in the constructor of StringBuilder) that<br>
        might be<br>
        good.<br>
<br>
<br>
    Sure, I'll add a comment. (But I don't think it's a big concern to<br>
    justify any major shuffle -- the ctor is right there inline to see<br>
    a few lines above, and it seems unlikely a stream adapter would<br>
    ever touch its storage unless written to.)<br>
<br>
<br>
        (insert various bikeshedding about the name - though I'm not<br>
        really<br>
        sure raw_ostream ever needed to adopt the C++ standard library<br>
        naming<br>
        convention in the first place, but I haven't looked closely)<br>
<br>
<br>
    So, I thought about that..<br>
<br>
    Having tried raw_string_builder_ostream, string_builder_ostream,<br>
    raw_string_builder, I ended up with StringBuilder as the only one<br>
    that looked beautiful in use.<br>
<br>
    Hard to say why, but it's probably because it has a dual role as<br>
    storage and streaming interface unlike the ostream adapter<br>
    classes, making the distinction significant.<br>
<br>
    Alp.<br>
<br>
<br>
<br>
        On Wed, Jun 11, 2014 at 9:25 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a><br></div></div><div><div class="h5">
        <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
            Replaces the pattern:<br>
<br>
               std::string buf;<br>
               raw_string_ostream os(buf);<br>
               ...<br>
               os.flush();<br>
               use(buf);<br>
<br>
            with:<br>
               StringBuilder os;<br>
               ...<br>
               use (os.str());<br>
<br>
            Benefits:<br>
<br>
              * Provides an inherently safe and opaque interface for<br>
            building std::string<br>
            instances<br>
              * Opens up the possibility of changing the underlying<br>
            storage in future.<br>
<br>
            Patch also converts various uses, some of which were<br>
            accessing the storage<br>
            without flushing.<br>
<br>
            Alp.<br>
<br>
            --<br>
            <a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
            the browser experts<br>
<br>
<br>
            ______________________________<u></u>_________________<br>
            llvm-commits mailing list<br></div></div>
            <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.<u></u>edu</a>><div class="">
<br>
            <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
<br>
<br>
    --     <a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
    the browser experts<br>
<br>
    ______________________________<u></u>_________________<br>
    llvm-commits mailing list<br></div>
    <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.<u></u>edu</a>><br>
    <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>