Introduce StringBuilder utility around raw_string_ostream

[Alp Toker]

On 12/06/2014 14:17, Yaron Keren wrote:
> This looks like a very useful class. It should work for the similar 
> SmallString pattern, right?
>
>   SmallString<256> OutName;
>   llvm::raw_svector_ostream Out(OutName);
> cast<ItaniumMangleContext>(CGM.getCXXABI().getMangleContext()).mangleCXXVTT(RD, 
> Out);
>   Out.flush();
>   StringRef Name = OutName.str();
>
> ->
>
>   StringBuilder Out;
> cast<ItaniumMangleContext>(CGM.getCXXABI().getMangleContext()).mangleCXXVTT(RD, 
> Out);
>   StringRef Name = Out.str();

Yeah, that'd work. But for cases like the above we should first provide 
a SmallString<> backed specialization that permits StringBuilder<256> Out;

The initial patch I posted is aimed more at the std::string-backed 
cases. A stack-allocating specialization should follow nicely from that.

Alp.


>
> Yaron
>
>
>
> 2014-06-12 8:01 GMT+03:00 Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>>:
>
>
>     On 12/06/2014 07:41, David Blaikie wrote:
>
>         (would find this a little easier to review if it were in Phab)
>
>         One off-the-cuff thought: If it's not already documented, you
>         might
>         want to put a comment in raw_string_ostream's ctor that
>         declares that
>         it /really shouldn't/ touch the string (since you're passing in an
>         object in the derived class that won't itself be constructed until
>         after the raw_string_ostream's ctor has finished). Or, better
>         yet, if
>         there's a way to build a raw_string_ostream without a string, then
>         attach it later (in the constructor of StringBuilder) that
>         might be
>         good.
>
>
>     Sure, I'll add a comment. (But I don't think it's a big concern to
>     justify any major shuffle -- the ctor is right there inline to see
>     a few lines above, and it seems unlikely a stream adapter would
>     ever touch its storage unless written to.)
>
>
>         (insert various bikeshedding about the name - though I'm not
>         really
>         sure raw_ostream ever needed to adopt the C++ standard library
>         naming
>         convention in the first place, but I haven't looked closely)
>
>
>     So, I thought about that..
>
>     Having tried raw_string_builder_ostream, string_builder_ostream,
>     raw_string_builder, I ended up with StringBuilder as the only one
>     that looked beautiful in use.
>
>     Hard to say why, but it's probably because it has a dual role as
>     storage and streaming interface unlike the ostream adapter
>     classes, making the distinction significant.
>
>     Alp.
>
>
>
>         On Wed, Jun 11, 2014 at 9:25 PM, Alp Toker <alp at nuanti.com
>         <mailto:alp at nuanti.com>> wrote:
>
>             Replaces the pattern:
>
>                std::string buf;
>                raw_string_ostream os(buf);
>                ...
>                os.flush();
>                use(buf);
>
>             with:
>                StringBuilder os;
>                ...
>                use (os.str());
>
>             Benefits:
>
>               * Provides an inherently safe and opaque interface for
>             building std::string
>             instances
>               * Opens up the possibility of changing the underlying
>             storage in future.
>
>             Patch also converts various uses, some of which were
>             accessing the storage
>             without flushing.
>
>             Alp.
>
>             --
>             http://www.nuanti.com
>             the browser experts
>
>
>             _______________________________________________
>             llvm-commits mailing list
>             llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>             http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>     -- 
>     http://www.nuanti.com
>     the browser experts
>
>     _______________________________________________
>     llvm-commits mailing list
>     llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>

-- 
http://www.nuanti.com
the browser experts