0. 序曲
寫這篇短文的起因是,前兩天想去天大的acm在線系統找幾道題做做。為什么呢?因為本人天大畢業,這個天大呢可是中國最早的大學,原名北洋大學堂,這可絕對是貨真價實的第一所大學。給大家推薦推薦啊,學風那是相當的好。
扯多了,還是回到本來的話題上。上了acm系統之后,就先看了1001。那道題的意思是輸入一些正整數(以EOF結束),把對應的字符輸出。這個簡單,程序很快就出來了:
#include <stdio.h>
int main()
{
int c;
while(scanf("%d", &c) != EOF)
{
putchar(c);
}
return 0;
}
程序運行,輸入103 102 105 107<enter>
輸出gfik。
當時運行完之后馬上想,為什么不是輸入一個數字馬上輸出一個字符呢,因為看程序確實是這樣的邏輯,只要不是EOF,就會輸出。又一想,對了,是緩沖的問題。想起來APUE里邊說得stdin應該是行緩沖的,另外,可以用setbuf,setvbuf設定流的緩沖。于是想將stdin設成無緩沖的。于是程序變成這樣:
#include <stdio.h>
int main()
{
int c;
setbuf(stdin, NULL);
while(scanf("%d", &c) != EOF)
{
putchar(c);
}
return 0;
}
可是編譯運行,還是老樣子,沒有變化。想了想,沒想出是啥原因,于是開始google和APUE。終于算是明白了些,整理在這兒。
聲明：
本文很大部分內容來自APUE－－UNIX環境高級編程。
1. 緩沖類型。
標準庫提供緩沖是為了減少對read和write的調用。提供的緩沖有三種類型(整理自APUE):
在這種情況下,實際的I/O操作只有在緩沖區被填滿了之后才會進行。對駐留在磁盤上的文件的操作一般是有標準I/O庫提供全緩沖。緩沖區一般是在第一次對流進行I/O操作時,由標準I/O函數調用malloc函數分配得到的。
術語flush描述了標準I/O緩沖的寫操作。緩沖區可以由標準I/O函數自動flush(例如緩沖區滿的時候);或者我們對流調用fflush函數。
在這種情況下,只有在輸入/輸出中遇到換行符的時候,才會執行實際的I/O操作。這允許我們一次寫一個字符,但是只有在寫完一行之后才做I/O操作。一般的,涉及到終端的流--例如標注輸入(stdin)和標準輸出(stdout)--是行緩沖的。
標準I/O庫不緩存字符。需要注意的是,標準庫不緩存并不意味著操作系統或者設備驅動不緩存。
ISO C要求:
但是,這并沒有告訴我們當標準輸入/輸出在涉及交互設備時,它們是無緩存的還是行緩存的;也沒有告訴我們標準錯誤應該是行緩存的還是無緩存的。不過,大多數實現默認的緩存類型是這樣的:
2. 改變默認緩存類型
可以通過下面的函數改變緩存類型(摘自APUE):
void setbuf(FILE *restrict fp, char *restrict buf);
int setvbuf(FILE *restrict fp, char *restrict buf, int mode,
size_t size);
這些函數必須在流打開之后、但是未對流做任何操作之前被調用(因為每個函數都需要一個有效的文件指針作為第一個參數)。
利用setbuf，可以打開或者關閉緩存。為了打開緩存，buf參數必須一個大小為BUFSIZ的緩存，BUFSIZ是定義在stdio。h中的常量。&lt;&lt;ISO/IEC
9899&gt;&gt;要求：BUFSIZ至少為256。如果要關閉緩存，可以將buf設成NULL。
利用setvbuf，我們可以設定緩存類型。這是通過mode參數指定的。
關于這兩個函數，可以看下表（摘自APUE）：
|
Function
|
mode
|
buf
|
Buffer and length
|
Type of
buffering
|
|
setbuf
|
|
non-null
|
user buf of length
BUFSIZ
|
fully buffered or line buffered
|
|
NULL
|
(no buffer)
|
unbuffered
|
|
setvbuf
|
_IOLBF
|
non-null
|
user buf of length size
|
fully buffered
|
|
NULL
|
system buffer of appropriate length
|
|
_IOFBF
|
non-null
|
user buf of length size
|
line buffered
|
|
NULL
|
system buffer of appropriate length
|
|
_IONBF
|
(ignored)
|
(no buffer)
|
unbuffered
|
需要注意的是：如果在函數內為流分配了自動變量作為緩存，那么在退出之前需要將流關閉。因此最好讓系統自己分配緩存，這些緩存在流關閉的時候會自動被釋放。
3.如果清理輸入緩存
關于這點可以參看comp.lang.c
FAQ的Question12.26b:
Q: If fflush won't work, what can I
use to flush input?
A: It depends on what you're trying to do. If you're
trying to get rid of an unread newline or other unexpected input after calling
scanf (see questions 12.18a-12.19), you really need to rewrite or replace the
call to scanf (see question 12.20). Alternatively, you can consume the rest of a
partially-read line with a simple code fragment like
while((c =
getchar()) != '\n' && c != EOF)
/* discard */ ;
(You may also
be able to use the curses flushinp function.)
There is no standard way to
discard unread characters from a stdio input stream. Some vendors do implement
fflush so that fflush(stdin) discards unread characters, although portable
programs cannot depend on this. (Some versions of the stdio library implement
fpurge or fabort calls which do the same thing, but these aren't standard,
either.) Note, too, that flushing stdio input buffers is not necessarily
sufficient: unread characters can also
accumulate in other, OS-level input buffers. If you're trying to actively
discard input (perhaps in anticipation of issuing an unexpected prompt to
confirm a destructive action, for which an accidentally-typed ``y'' could be
disastrous), you'll have to use a system-specific technique to detect the
presence of typed-ahead input; see questions 19.1 and 19.2. Keep in mind that
users can become frustrated if you discard input that happened to be
typed too quickly.
References: ISO Sec. 7.9.5.2
H&S Sec.
15.2
4. 幾點需要注意的地方
- 對輸入流進行fflush操作是無定義的。
- 無緩存并不意味著一個個的那樣處理輸入，而是說當操作系統返回它們時，對于標準庫函數來說它們是立即可用的。因為還可能有操作系統級甚至是硬件級的緩存，這些并不是setbuf可以控制的。
- 另外可以參考這里（我就是最先從這里開始看的）。還有這里。我從后面那個鏈接摘錄一些重要的下來：
setbuf() has to do with the
delivery of bytes between the
C library FILE* management layer and the OS I/O
layer.
Calls to fread(), fgets(),
fgetc(), and getchar() work within
whatever FILE* buffered data is available,
and when that data
is exhausted, the calls request that the FILE* buffer be
refilled
by the system I/O layer.
When full buffering is turned
on, that refill operation results in the
FILE* layer requesting that the
operating system hand it a full
buffer's worth of data; when buffering is
turned off, that
refill operation results in the FILE* layer requesting that
the
operating system return a single character.
...setting an input stream to
be unbuffered
does NOT tell the operating
system to tell the device driver
to go into any kind of "raw"
single-character mode. There are
system-specific calls such as ioctl() and
tcsetterm() that
control what the device driver will
do.