<div dir="ltr">FWIW, I like Alp's suggestion. There are a bunch of ways to do string building in LLVM (Twine, raw_string_ostream, std::stringstream). I'd appreciate a single mechanism for making strings.<div><br></div>
<div>And the important thing I as a user would love to see is checking. Am I performing unsafe operations? Will my call result in references to deallocated storage? My experience with Twine has been a succession of "bugger, that was a reference to a temporary object. Add a .str() here" until it works.</div>
<div><br></div><div>Alp's suggestion seems to fit that usecase, make it simpler, and make it more efficient. So I'm all for it.</div><div><br></div><div>James</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 12 June 2014 16:58, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="">On Thu, Jun 12, 2014 at 4:52 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


The existing stream classes are really light append-only non-seekable streams. reset() is a higher-level feature that makes onerous assumptions about storage, both "what it can do" and "what we're allowed to do with it".<br>


<br>
So to put reset() or seeking operations inside the primitive ostream subclasses would be quite a layering violation.</blockquote><div><br></div></div><div>I dunno. raw_string_ostream has a 'str' method that returns a std::string reference. I don't know what we could possibly do to this class that would more tightly couple it to the underlying storage. ;]</div>

<div><br></div><div>But I'm not asking you to add this functionality, just saying that if this is a problem in practice there seems to be an easy solution.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
<br></div>
I can't see how that'd be done without making a muddle of the ostream primitive classes. Adding optional storage to a "simple adaptor class" strikes me as a poor idea because it'd no longer be usable be a thin interface that's easily inheritable.<br>

</blockquote><div><br></div></div><div>I don't see why raw_string_ostream is a thin interface or is easily inheritable. I think it probably should be declared as final. It is a very specific, concrete wrapper around a std::string and a raw_ostream. Same goes for the svector variant.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At 25 LoC the proposed implementation is still pretty tight even after adding the stack allocation facility. And it doesn't hack up ostream classes, and fixes various points of use, all clear pluses to me.</blockquote>

</div></div><br></div><div class="gmail_extra">We disagree here, restating things seems unlikely to progress anything.</div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">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/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>