Re:How fast is fscanf?
by acqq on Monday October 06, 2014 @02:52AM
(#8414586)
The "lean C program" alternative author presents is neither the correct equivalent of fscanf nor technically correct, and people here recognized this, my attempt to summarize:
- The proper conversion has enough corner cases that naive implementation practically certainly misses. Author's version produces provably different results than the library one for a lot of the same inputs.
- The fscanf must process the format string on every call, therefore we're not comparing the same functionality. There are library functions that don't need the format string to work.
- The standard library must be able correctly process Unicode and locales.
See the other comments for more details. Of course, it can be that the author doesn't need more than what he implemented, but he didn't discuss the tradeoffs or incorrect reading in the article and the other readers are advised to investigate more before using his code.
Re:How fast is fscanf?
by rbehrends on Monday October 06, 2014 @06:19AM
(#8415077)
Another source of overhead is that fscanf() on POSIX systems (like most operations on FILE *) is required to lock the underlying FILE structure. Even without contention, the overhead is non-trivial.
- The proper conversion has enough corner cases that naive implementation practically certainly misses. Author's version produces provably different results than the library one for a lot of the same inputs.
- The fscanf must process the format string on every call, therefore we're not comparing the same functionality. There are library functions that don't need the format string to work.
- The standard library must be able correctly process Unicode and locales.
See the other comments for more details. Of course, it can be that the author doesn't need more than what he implemented, but he didn't discuss the tradeoffs or incorrect reading in the article and the other readers are advised to investigate more before using his code.