Reply to thread

Message: [QUOTE="Eric Sosman, post: 5028996"] They are "convenience functions" in the sense that you could use repeated calls to fgetc/fputc (or getc/putc) to do pretty much the same thing, transferring one byte per call. Since you transfer (potentially) many bytes per call fread/fwrite could be a bit faster than byte-at-a-time loops, but since most CPU's are millions of times faster than most I/O devices any gains are unlikely to matter. Here's a closer look at fread; fwrite is similar. First, the declaration (slightly simplified): size_t fread( void * ptr, // where the input data will land size_t size, // the size of one data element size_t nmemb, // the number of elements to read FILE * stream // the source from which they're read ); The first likely point of bafflement is this "element" business. fread/fwrite don't (necessarily) deal in single bytes, but in units of (potentially) multi-byte items. To read an array of forty-two something-or-others, you might use fread(array, sizeof array[0], 42, stream); If one something-or-other occupies ten bytes this will read 420 bytes; if it occupies just one byte this reads 42 bytes. The main thing to keep in mind is that it reads 42 something-or-others of `sizeof array[0]' bytes each. Digression: Have you encountered other functions that deal in "elements" of a specified size instead of directly with bytes? Sure you have: There's qsort and bsearch, and for that matter calloc: Each has a pair of arguments that specify an element size and an element count. But be alert! Notice that qsort et al. describe their elements the other way around: "count followed by size," whereas fread/fwrite use "size followed by count." You've heard, perhaps, of the "cathedral versus bazaar" approaches to system design? C's library arose from the bazaar, and is occasionally, er, bizarre. Okay, but what difference does it make? The number of bytes transferred will be the product of the two arguments, and so will be the same whichever way you specify them, right? Yes, but then there's the matter of the value returned by the function: It's the number of *elements* transferred, not the number of bytes. If you read 42 10-byte elements or 10 42-byte elements you'll read 420 bytes either way, but one fread call will say "You got 42 elements" and the other will say "You got 10 elements." Assuming you'll use the returned value to figure out how many elements your program should now digest, you'll want to keep size and count straight lest you wind up reading 10 and trying to process 42, or reading 42 but processing only the first 10! One problem with reporting the number of "elements" read or written is that if you get an I/O error or end-of-file in the middle of an element it's hard to determine exactly how far you got. For example, if you try to read 42 10-byte elements and fread says you got 16, you can't tell whether you got exactly 16, or 16 plus four bytes of a 17th and then EOF. A way around this is to use one as your element size: size_t bytes = fread(array, 1, 42 * sizeof array[0], stream); size_t count = bytes / sizeof array[0]; size_t excess = bytes % sizeof array[0]; if (excess != 0) { // Stopped in mid-element; something's strange. // Maybe use feof(stream) and/or ferror(stream) // and/or perror() to diagnose the problem. ... I hope this helps. [/QUOTE]

Verification