PE> fgets() would be faster after fread() if the fread() had just
PE> loaded a 512-byte buffer for you, and now your fgets is just
PE> reading out of the buffer, instead of the fgets() having to do
PE> both.
BL> Eh? I thought everything got closed down at the end of the function?
Local variables disappear.
BL> It *must* do... otherwise you'd run out of stack space.
Your file pointer is not a variable that is local to fopen() or fread(). If
it was, it would have disappeared after fopen(), and you could never use
the file. Hardly very useful.
PE> It's a macro instead of a function call.
BL> Doesn't that mean it just calls another function?
PE> No. It can, but normally getc() is implemented by a 6-line
PE> macro which just accesses a the buffer directly.
BL> Whooo... can you do that??
BL> ... [later - is this it?]
BL> #define getc(f) \
BL> ((--((f)->level) >= 0) ? (unsigned char)(*(f)->curp++) : \
BL> _fgetc (f))
BL> Gee... 6 lines, my arse. This opens up whole new possibilities! I
Well, that's because Borland's a heap of shit. That's why others are much
faster at files. The only reason that simple thing works is because
they've already parsed all the characters in the buffer once already.
Here's Watcom's...
#define getc(fp) \
((fp)->_cnt<=0 \
|| (fp)->_flag&_UNGET \
|| (*(fp)->_ptr)=='\x0d' \
|| (*(fp)->_ptr)=='\x1a' \
? fgetc(fp) \
: ((fp)->_cnt--,*(fp)->_ptr++))
BL> already knew that this was one of the things C had over Pascal, but
BL> that's terrific! But it does call fgetc(F) to fill up the buffer.
So?
BL> What's a one-byte buffer called?
PE> Pass. Who's using a 1-byte buffer? BFN. Paul.
BL> I assumed getc() was just calling the other one every time... it
BL> never occurred to me that it could read straight out of the stream and
BL> top it up every so often.
I didn't suggest you try getc() in the crc program you were running just
for fun. It's actually a bad habit of mine using fgetc() instead of
getc(). Maybe even worse than not spending the effort to use a proper
buffer. :-) I would actually have to do some trials on both before I knew
whether it was worth changing though. BFN. Paul.
@EOT:
---
* Origin: X (3:711/934.9)
|