Question

Everywhere I see "it is practically identical", or something similar...

From The GNU C Programming Tutorial :

There is another function in the GNU C Library called fgetc. It is identical to getc in most respects, except that getc is usually implemented as a macro function and is highly optimised, so is preferable in most situations. (In situations where you are reading from standard input, getc is about as fast as fgetc, since humans type slowly compared to how fast computers can read their input, but when you are reading from a stream that is not interactively produced by a human, fgetc is probably better.)

What are the other differences? I have heard that they each have a different implementation (and one can be used as a macro) but, what makes them soo different (or different enough) for them to be both in the Standard C library (or specification)?

Was it helpful?

Solution

From the Advanced Programming in Unix Environment:

...

The difference between getc and fgetc is that getc can be implemented as a macro, whereas fgetc cannot be implemented as a macro. This means three things:

  • The argument to getc should not be an expression with side effects.
  • Since fgetc is guaranteed to be a function, we can take its address. This allows us to pass the address of fgetc as an argument to another function.
  • Calls to fgetc probably take longer than calls to getc, as it usually takes more time to call a function.

...

OTHER TIPS

Seems like the differences are, in 99.9% of the cases, meaningless.

One point which may make a difference - The man page says getc() may be implemented as a macro which evaluates stream more than once.

It could lead to strange behavior in some (not very useful) cases, e.g.:

FILE *my_files[10] = {...}, *f=&my_files[0];
for (i=0; i<10; i++) {
    int c = getc(f++);    // Parameter to getc has side effects!
}

If getc evaluates f++ more than once, it will advance f more than once per iteration. In comparison, fgetc is safe in such situations.

There are essentially the same (or similar enough to not bother). You should look at their implementation: GNU libc and MUSL libc are free software implementations. And they now could be implemented as inline functions (which are as fast as macros).

And I won't bother that much. In real life, I/O is mostly constrained by hardware (e.g. the time to access the disk).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top