まず、fdopen を使用する特別な理由はありません。 fopen の場合 はオプションで、open 他の可能な選択肢です。 open を使うべきではありませんでした FILE * が必要な場合は、最初にファイルを開く . fdopen を含む そのリストの は、他のものとあまり似ていないため、正しくなく、混乱を招きます。ここでの重要な違いは C 標準の FILE * と および OS 固有のファイル記述子。
fopen を使用する主な理由は 4 つあります。 open の代わりに .
fopen open で行っているよりもはるかに高速であることが判明するバッファリング IO を提供します。 .fopen ファイルがバイナリ モードで開かれていない場合、行末の変換を行います。これは、プログラムが Unix 以外の環境に移植された場合に非常に役立ちます (世界は LF のみに収束しているように見えますが (IETF テキストベースのネットワーキングを除く)。 SMTP や HTTP などのプロトコル)).FILE * fscanf を使用できるようになります およびその他の stdio 関数。open をサポートしない他のプラットフォームに移植する必要があるかもしれません。 関数。
私の意見では、行末の翻訳はあなたを助けるよりも邪魔になることが多く、 fscanf の解析は は非常に弱いため、必然的に、より有用なものを優先して捨ててしまいます。
そして C をサポートするほとんどのプラットフォームには open があります 関数。
バッファリングの問題が残ります。主にファイルを順番に読み書きする場所では、バッファリングのサポートが非常に役立ち、速度が大幅に向上します。しかし、データがファイルにあるはずのときにデータがファイルに入らないという興味深い問題が発生する可能性があります。 fclose まで覚えておいてください または fflush
シークを行っている場合 (別名 fsetpos または fseek 2 番目は、標準に準拠した方法で使用するのが少しトリッキーです)、バッファリングの有用性はすぐに低下します。
もちろん、私の偏見は、私はソケットを頻繁に使用する傾向があるということです。実際には、非ブロッキング IO (FILE *) を実行したいという事実があります。 合理的な方法で完全にサポートできません) バッファリングがまったくなく、多くの場合、複雑な解析要件が実際に私の認識を彩ります。
fopen と C でのオープン
1) fopen ライブラリ関数です open の間 システムコールです .
2) fopen バッファリングされた IO を提供します open に比べて高速です バッファリングされていない .
3) fopen ポータブルです open の間 ポータブルではありません (オープンは環境固有です ).
4) fopen FILE 構造体 (FILE *) へのポインタを返します; open ファイルを識別する整数を返します。
5) FILE * fscanf を使用できるようになります およびその他の stdio 関数。
open() 低レベルの os 呼び出しです。 fdopen() OS レベルのファイル記述子を C 言語の高レベルの FILE 抽象化に変換します。 fopen() open() を呼び出します バックグラウンドでファイルポインターを直接提供します。
生のファイル記述子ではなく FILE オブジェクトを使用することにはいくつかの利点があります。これには、使いやすさだけでなく、組み込みのバッファリングなどの他の技術的な利点も含まれます。特にバッファリングは、一般にかなりのパフォーマンス上の利点をもたらします。