[patch][rfc] Add pwrite to raw_stream

[Chandler Carruth]

On Wed, Apr 8, 2015 at 8:42 PM Rafael Espíndola <rafael.espindola at gmail.com>
wrote:

> On 8 April 2015 at 23:34, Chandler Carruth <chandlerc at google.com> wrote:
> > Sorry I'm late to the party, but I think I agree with Sean.
> >
> > This makes absolutely no sense to me on the raw_ostream interface. That
> > interface is entirely about streaming output. I don't think the seek
> > interface makes any sense either honestly.
> >
> > I think the right way to layer these things is the other way around.
> Build
> > the abstraction you want for IO, but don't tie it to raw_ostream in any
> way.
> > You could make it *also* implement the raw_ostream interface if you want
> so
> > that you can use it in that context, but I don't know why raw_ostream
> would
> > ever be aware of this.
>
> So, what is needed is a thing, such that
>
> * Thing has the operations provided by the raw_ostream
>

I'm surprised by this, FWIW.

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?

I feel like the object writer should be using a much simpler abstraction...

* Thing has pwrite and/or seek.
> * The object writer/streamer takes a thing instead of a plain raw_ostream.
> * The thing can directly write to disk or hold data in a buffer and
> dump it in the end.
>
> Would it work for you to have thing be raw_pwrite_streamer and
>

I think its not a "streamer" and probably shouldn't try to follow the
std::ostream interface patterns (including name).


>
> raw_pwrite_streamer inherits from raw_ostream.
>

If being able to pass this thing to raw_ostream-accepting interfaces is
actually critical, sure.


> raw_fd_stream inherits from raw_pwrite_streamer
> raw_svector_stream inherits from raw_pwrite_streamer
> the object writer/streamer takes a raw_pwrite_streamer
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150409/539a6406/attachment.html>