C fopen vs open [英] C fopen vs open
问题描述
您是否有任何理由(语法除外)想要使用
Is there any reason (other than syntactic ones) that you'd want to use
FILE *fdopen(int fd, const char *mode);
或
FILE *fopen(const char *path, const char *mode);
代替
int open(const char *pathname, int flags, mode_t mode);
在 Linux 环境中使用 C 时?
when using C in a Linux environment?
推荐答案
首先,如果 fopen
是一个选项并且 没有特别好的理由使用
是另一种可能的选择.如果您想要 fdopen
>openFILE *
,您首先不应该使用 open
打开文件.因此,在该列表中包含 fdopen
是不正确且令人困惑的,因为它与其他列表不太一样.我现在将忽略它,因为这里的重要区别在于 C 标准 FILE *
和特定于操作系统的文件描述符之间.
First, there is no particularly good reason to use fdopen
if fopen
is an option and open
is the other possible choice. You shouldn't have used open
to open the file in the first place if you want a FILE *
. So including fdopen
in that list is incorrect and confusing because it isn't very much like the others. I will now proceed to ignore it because the important distinction here is between a C standard FILE *
and an OS-specific file descriptor.
使用 fopen
而不是 open
的主要原因有四个.
There are four main reasons to use fopen
instead of open
.
fopen
为您提供缓冲 IO,结果可能比您使用open
所做的要快得多.fopen
如果文件不是以二进制模式打开,则执行行结束转换,如果您的程序曾经被移植到非 Unix 环境,这会非常有用(尽管世界似乎正在收敛仅在 LF 上(除了 IETF 基于文本的网络协议,如 SMTP 和 HTTP 等)).FILE *
使您能够使用fscanf
和其他 stdio 函数.- 您的代码有一天可能需要移植到其他仅支持 ANSI C 且不支持
open
功能的平台.
fopen
provides you with buffering IO that may turn out to be a lot faster than what you're doing withopen
.fopen
does line ending translation if the file is not opened in binary mode, which can be very helpful if your program is ever ported to a non-Unix environment (though the world appears to be converging on LF-only (except IETF text-based networking protocols like SMTP and HTTP and such)).- A
FILE *
gives you the ability to usefscanf
and other stdio functions. - Your code may someday need to be ported to some other platform that only supports ANSI C and does not support the
open
function.
在我看来,行尾翻译通常会妨碍您而不是帮助您,并且 fscanf
的解析非常薄弱,以至于您最终不可避免地将其丢弃而支持更有用的东西.
In my opinion the line ending translation more often gets in your way than helps you, and the parsing of fscanf
is so weak that you inevitably end up tossing it out in favor of something more useful.
大多数支持 C 的平台都有 open
功能.
And most platforms that support C have an open
function.
这就留下了缓冲问题.在您主要按顺序读取或写入文件的地方,缓冲支持确实很有帮助,并且速度大大提高.但它可能会导致一些有趣的问题,即当您期望数据存在时,数据并未最终出现在文件中.你必须记住在适当的时候 fclose
或 fflush
.
That leaves the buffering question. In places where you are mainly reading or writing a file sequentially, the buffering support is really helpful and a big speed improvement. But it can lead to some interesting problems in which data does not end up in the file when you expect it to be there. You have to remember to fclose
or fflush
at the appropriate times.
如果您正在执行搜索(又名 fsetpos
或 fseek
,其中第二个以符合标准的方式使用稍微有点棘手),缓冲的用处很快下来.
If you're doing seeks (aka fsetpos
or fseek
the second of which is slightly trickier to use in a standards compliant way), the usefulness of buffering quickly goes down.
当然,我的偏见是我倾向于大量使用套接字,并且事实上您确实想要进行非阻塞 IO(FILE *
完全无法支持)以任何合理的方式)根本没有缓冲,而且经常有复杂的解析要求,这确实影响了我的看法.
Of course, my bias is that I tend to work with sockets a whole lot, and there the fact that you really want to be doing non-blocking IO (which FILE *
totally fails to support in any reasonable way) with no buffering at all and often have complex parsing requirements really color my perceptions.
这篇关于C fopen vs open的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!