<div dir="ltr"><div class="gmail_quote">On Wed, Apr 8, 2015 at 8:42 PM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8 April 2015 at 23:34, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
> Sorry I'm late to the party, but I think I agree with Sean.<br>
><br>
> This makes absolutely no sense to me on the raw_ostream interface. That<br>
> interface is entirely about streaming output. I don't think the seek<br>
> interface makes any sense either honestly.<br>
><br>
> I think the right way to layer these things is the other way around. Build<br>
> the abstraction you want for IO, but don't tie it to raw_ostream in any way.<br>
> You could make it *also* implement the raw_ostream interface if you want so<br>
> that you can use it in that context, but I don't know why raw_ostream would<br>
> ever be aware of this.<br>
<br>
So, what is needed is a thing, such that<br>
<br>
* Thing has the operations provided by the raw_ostream<br></blockquote><div><br></div><div>I'm surprised by this, FWIW.</div><div><br></div><div>Whether it really makes sense or not, most of the raw_ostream interface is around formatting output in textual ways. Is the interface that you want really related to that at all?</div><div><br></div><div>I feel like the object writer should be using a much simpler abstraction...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Thing has pwrite and/or seek.<br>
* The object writer/streamer takes a thing instead of a plain raw_ostream.<br>
* The thing can directly write to disk or hold data in a buffer and<br>
dump it in the end.<br>
<br>
Would it work for you to have thing be raw_pwrite_streamer and<br></blockquote><div><br></div><div>I think its not a "streamer" and probably shouldn't try to follow the std::ostream interface patterns (including name).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
raw_pwrite_streamer inherits from raw_ostream.<br></blockquote><div><br></div><div>If being able to pass this thing to raw_ostream-accepting interfaces is actually critical, sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
raw_fd_stream inherits from raw_pwrite_streamer<br>
raw_svector_stream inherits from raw_pwrite_streamer<br>
the object writer/streamer takes a raw_pwrite_streamer<br></blockquote><div><br></div><div>Related to the above, I suspect that most of the consumers of raw_fd_stream and raw_svector_stream have remarkably different constraints from the object writer. It seems weird to try to serve both of their needs via the same interface.</div></div></div>