長さについて仮定せずにテキスト行 (改行で終了) を読む必要があります。だから私は今可能性に直面しています：
fgets最後の文字が改行であるかどうかを毎回使用して確認し、継続的にバッファに追加しますfgetc、場合によっては各文字を読み取るrealloc直観は、fgetcバリアントの方が遅い可能性があることを示していますが、すべての文字を調べずにそれを行う方法がわかりませんfgets(また、私の直観は常にそれほど良いとは限りません)。ラインは非常に大きいため、パフォーマンスが重要です。
それぞれのアプローチの長所と短所を知りたいです。前もって感謝します。
fgets()動的メモリ割り当てと組み合わせて使用することをお勧めします-またはgetline()、POSIX 2008 標準にあり、最近の Linux マシンで利用できるインターフェイスを調査できます。これにより、メモリ割り当てが行われます。バッファーの長さとそのアドレスを把握しておく必要があります。そのため、情報を処理するための構造を自分で作成することもできます。
これfgetc()も機能しますが、わずかに手間がかかりますが、わずかにそうです。カバーの下では、 と同じメカニズムを使用しfgets()ます。内部は、直接strchr()呼び出した場合には利用できない、より高速な操作を利用できる可能性があります (に似ています)。fgetc()
あなたの環境はgetline(3)機能を提供していますか？もしそうなら、私はそれのために行くと思います。
私が見る大きな利点は、(必要に応じて) バッファー自体を割り当て、realloc()小さすぎる場合に渡すバッファーを割り当てることです。(これは、 から取得したものを渡す必要があることを意味しますmalloc())。
これにより、fgets/fgetc の苦労がいくらか解消されます。また、fgets/fgetc を実装する C ライブラリを作成した人が、効率化を図ってくれたことを期待できます。
おまけ: Linux の man ページには、効率的な方法での使用方法の良い例があります。
パフォーマンスが重要な場合は、通常、getc代わりにを呼び出しますfgetc。getc標準では、関数呼び出しのオーバーヘッドを回避するために、マクロとして実装しやすくしようとしています。
それを過ぎると、おそらく対処すべき主なことは、バッファを割り当てる際の戦略です。ほとんどの人は固定増分を使用します (たとえば、スペースが不足した場合は、さらに 128 バイトを割り当てます)。代わりに定数factorを使用することをお勧めします。したがって、スペースが不足した場合は、以前のサイズの 1 1/2 倍のバッファーを割り当てます。
特にがマクロとして実装されている場合、とgetcの違いは通常非常に小さいため、他の問題に集中することをお勧めします。getcfgets
行の最大長を設定できれば、長いものでもfgets問題ありません。そうでない場合でも、複数の呼び出しのオーバーヘッドが大きくなるため、複数の呼び出しfgetsは複数の呼び出しよりも高速になります。fgetc
ただし、より良い答えは、パフォーマンスの違いについて心配する価値はないということです。が十分に速い場合fgetc、それは何を意味しますか?
行末まで読み取っていない場合は、大きなバッファーを割り当ててから、fgets、チェック、再割り当て、繰り返しを使用します。
(fgetc または fgets を介して) 読み取るたびに、時間がかかるシステム コールを作成しているため、発生する回数を最小限に抑える必要があるため、fgets の呼び出し回数を減らし、メモリ内での反復処理を高速化します。
ファイルから読み取る場合は、ファイルをmmap()ing することも別のオプションです。