<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">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>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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<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>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> </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><br></div><div class="gmail_extra">We disagree here, restating things seems unlikely to progress anything.</div></div>