Hi,
There are three type of buffering: Fully buffered,line buffered,and unbuffered. The goal of the buffering provided by the standard I/O library is to use the minimum number of read and write calls.
I understand that decrease write() calls when use output function output data to a file , just like fputc().
Fully buffered: when the standard I/O buffer is filled,call write().
Line buffered: when a newline character encountered,call write().
Unbuffered: directly call write().
However, In input function case,just like use fgetc() input data from a file,we can use setvbuf() change buffer mode. then,how work the fgetc()? whether the buffer effect to decrease read() calls? especially line buffered? In my opinion, read() is not the ability to read a line.
I just found out the work of input buffer in glibc2.2.5.
At std input, like fgetc(), that finally call the __read() in fillbuf().
The following results:
fillbuf() check unbuffered, check fully buffered. but it doesn't chek line buffer.So
Unbuffered: read a character every time.
Fully buffered:__read() try to fill the buffer, except for encounter a EOF.
Line buffered:it doesn't affect the __read().If stream fp have the buffer,it behavior like Full buffer. If have no buffer, like Unbuffered.
For a stream, the terminal default use line buffer. And else default use fully buffered. If you want to use a nubuffered, you nee set the pf->__userbuf of FILE struct(use setvbuf()) before any other I/O operation is performed on the stream.
I have another question, When I view the source code for glibc2.2.5, many functions can be found in. But in the higher version, such as glibc2.9, many functions can't be found,Such as fgetc(),why? Is it in assembly?
I doubt they'd use assembly. That'd be a nightmare to try and keep working in a portable open-source library, and fairly pointless in high-level code like this.
They must be in there somewhere, but where might not be obvious if they've tried to modularize it or wrapp it in macros or something.
I doubt they'd use assembly. That'd be a nightmare to try and keep working in a portable open-source library, and fairly pointless in high-level code like this.
Assembly for an open-source library? Just like you said, it'd be horrible to try and manage! With constant updates, changes, etc. 50 lines is enough for me to try and manage, after that, It just gets annoying.
Hi Everybody,
Can anyone guide me how to install SGI's STL Library on Solaris 8.0 ?
Out of SGI's STL and STLPort, which third party STL is suitable, stable and thread-safe for UNIX Platform ?
Please guide me over the above issue .
Thanks & Regards
Dinesh-Ahuja (0 Replies)