[PATCH] D91693: [Support] Add reserve() method to the raw_ostream.

[Pavel Labath via Phabricator via llvm-commits]

labath added a comment.

In D91693#2407604 <https://reviews.llvm.org/D91693#2407604>, @avl wrote:

>> Not really. :( For resize, I would expect that it has a physical effect on the underlying object (changing file size), which is good, I guess. But I would still expect that it is possible to write more data than that size, and have it be appended, as that's what our other streams do. I would also expect this operation to also have some effect on raw_string_ostream (changing the underlying string size) and such. And I am still worried about using mmap(2)/write(2) interchangeably. The two apis have different characteristics, and I don't think that can be conveyed by a single method call. E.g., the mmap approach will not respect O_APPEND, it will cause SIGBUS if the file is concurrently truncated (that's why our mmap APIs like MemoryBuffer have IsVolatile arguments), etc.
>
> I see. So the better solution would be resizable raw_mmap_ostream which could be used in that scenario(when the size is not known at creation time):

Yes, *I* would think so. You may want to gather additional opinions before spending too much time on that, though...

>> TBH, I am not sure that raw_ostream is the best class for this use case. How much of it's functionality do you need? If you don't need the formatted output capabilities, then maybe a different interface might be better suited. (I realize you're trying to remove one.)
>
> I think I do not need formatted output capabilities. They could probably be nice to have in some cases. But main functionality which is useful - possibility to write data as a sequence of pieces. i.e. not as one huge chunk, but as a series of smaller chunks.

Yeah, I suppose that's reasonable. Though, if the scope of this is small (e.g.: it only needs to write to files _or_ memory buffers, and it's not going go have a lot of callers/large surface area), I would not completely dismiss some custom solution either...

> Speaking of reserve() method. Do you think it would be useful to implement it in the sense of hint? The only practical implementation for the current moment would be reservation underlying string by raw_string_ostream? It might be useful for the future raw_mmap_ostream, but it would depend on implementation.

I don't think that would be *un*reasonable, but I'd wait until a use case for it shows up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91693/new/

https://reviews.llvm.org/D91693