3 ms·
I mentioned Java didn't I? Even in the pre-NIO APIs: If you try to write a string to a FileOutputStream the way that Rust code did this is what it looks like:
by BoorishBears 5y ago
I mentioned Java didn't I? Even in the pre-NIO APIs:
If you try to write a string to a FileOutputStream the way that Rust code did this is what it looks like:
byte[] byteString = "Hello World".getBytes(StandardCharsets.US_ASCII);
myStream.write(byteString, 0, byteString.length);
But if you use a FileWriter, which has a built-in buffer and wraps the OutputStream:
myWriter.write("Hello World");
For me, if the Rust example had required a length and offset, I'd immediately assume it was unbuffered. I keep clarifying: I realize it's not a rule, but I guess that's just a pattern I've seen across a lot of languages. Maybe because it somewhat matches write(2)?
- xxs 5y agoIndeed, Reader/Writer framerwork provides buffering (esp. now). However, in my experience the writers are not very commonly used which is a stark contrast to BufferedReader that's everywhere (it comes with readLine()). Instead, writing is commonly implemented via encoding/conversion/etc. to a byte[] and then written directly to the output stream.