4 ms·
read_line returning the number of bytes read instead of the bytes is a C thing. That's just how you do things in C. Not arguing it's the best way -- and I far
by jki275 6y ago
read_line returning the number of bytes read instead of the bytes is a C thing. That's just how you do things in C.
Not arguing it's the best way -- and I far prefer the C++ way of returning a string or a buffer -- but it's the C way.
- twic 6y agoIt's how Java's InputStream and Reader work, too. In any language, requiring the caller to supply the buffer is a prerequisite for efficiency.
- estebank 6y agoAs the sibling comment said it's not a C thing. It is done that way in C because you have to babysit allocations. Other languages aimed at ease of use will just allocate for you and give you the fully baked contents in a single fn call, but when you're writing code that 1) has to be called often enough where allocations can show up in your flame graphs or 2) the input is big enough that you can't realistically keep the entire thing in memory at once, you suddenly have to care about what the fn is doing internally. Making the default API for file interaction require you pass in your own buffer makes this explicit at the cost of some ease of use. Seeing this will also serve as a teachable moment, when the dev looks at the docs trying to understand why it has such an obtuse API, hopefully coming away with this comment's explanation. This might seem to be a pedantic distinction but I've seen Java codebases where buffer reuse was mandatory in the hot path and Rust is all about removing foot guns.
- jki275 6y agoI agree with you on why it’s done that way in C, and certainly it can be in other languages. No argument there. But it really is a C thing, because that’s just “how you do it” in C.