使用したい理由がありますか（構文上の理由以外）
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を使用する場合
第一に、がオプションであり、それが他の可能な選択肢であるfdopen場合に使用する特に良い理由はありません。必要な場合は、最初からファイルを開くために使用するべきではありませんでした。そのため、そのリストに含めることは、他のものとあまり似ていないため、不正確で混乱を招きます。ここで重要な違いはC標準とOS固有のファイル記述子の間であるため、ここでは無視します。fopenopenopenFILE *fdopenFILE *
のfopen代わりに使用する主な理由は4つありますopen。
fopenでは、バッファリングIOが提供されますopen。これは、実際の処理よりもはるかに高速になる場合があります。fopen ファイルがバイナリモードで開かれていない場合、行末変換を実行します。これは、プログラムが非UNIX環境に移植された場合に非常に役立ちます（ただし、世界はLFのみに収束しているように見えます（IETFテキストベースのネットワークを除く）。 SMTPやHTTPなどのプロトコル））。FILE *を使用するfscanfと、その他のstdio関数を使用できます。open関数をサポートしない他のプラットフォームにコードを移植する必要がある場合があります。私の意見では、行末の翻訳はあなたを助けるよりも頻繁に邪魔になり、構文解析fscanfは非常に弱いので、あなたは必然的にもっと有用なものを優先してそれを投げ出すことになります。
また、Cをサポートするほとんどのプラットフォームにはopen関数があります。
それはバッファリングの問題を残します。主に順次ファイルの読み取りまたは書き込みを行う場所では、バッファリングのサポートが非常に役立ち、速度が大幅に向上します。しかし、データがファイルにあると予想しても、データがファイルに含まれないという興味深い問題が発生する可能性があります。あなたは、fcloseまたはfflush適切な時に覚えておく必要があります。
シークを行っている場合（別名fsetposまたはfseekその2番目は、標準に準拠した方法で使用するには少しトリッキーです）、バッファリングの有用性はすぐに低下します。
もちろん、私のバイアスは、私がソケットをよく使用する傾向があること、そしてFILE *バッファリングなしで頻繁に非ブロッキングIO（まったく合理的な方法でサポートに失敗する）を本当に実行したいという事実です複雑な構文解析要件があるため、私の認識は本当に変わります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加