3 ms·
> Also, stream communication is explicitly two-sided; if you want to pull in a value on an istream, there needs to be a corresponding process on the other side
by shakna 8y ago
> Also, stream communication is explicitly two-sided; if you want to pull in a value on an istream, there needs to be a corresponding process on the other side inserting something into an ostream.
That's not always the case is it, though? stdin on a standard computer for one, and in embedded world you might have an ostream to speak UART and give yourself a nice printing function, but you probably won't have a corresponding istream.
So why can't this be similarly exceptional?
- xiii1408 8y agoThat's true--you can add the ability to seek, in which case the stream becomes like a file. Whether or not that's desirable depends on what kind of programs you're writing. For programs like databases that traditionally store things using the filesystem, that's probably a very useful abstraction, and some people at VMware have actually implemented an "RDMA over the filesystem" abstraction, which is super cool: https://256fd102-a-62cb3a1a-s-sites.googlegroups.com/site/mkaguilera/remote-regions-atc2018.pdf https://256fd102-a-62cb3a1a-s-sites.googlegroups.com/site/mk.... If you're looking for an abstraction with which to directly implement programs that use data structures, however, I still think pointers are much more valuable than files because files are not strongly typed, and it's easy to read junk due to type errors and lack of structure.