Introduce StringBuilder utility around raw_string_ostream

[David Blaikie]

(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.

(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)

On Wed, Jun 11, 2014 at 9:25 PM, Alp Toker <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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>