2015-12-03 11 views
5

私の知る限りFILE *で作業するのではなく、ファイル記述子で動作するgetline()に相当するlibcはありません。ファイルポインタの代わりにファイル記述子を持つgetline()

(技術的な)理由はありますか?

+1

'getline'はCの標準ではありませんが、POSIXの機能を意味すると思いますか? –

+0

用語ファイル記述子は主観的なので、IOFileからソケットまで何でも構いません。ファイルに非常に関連しない限り、読み込み行は実装する正しい方法ではないかもしれません。 –

答えて

7

fdopenでファイル記述子のFILEストリームを作成できます。

一般に、ファイルディスクリプタから行を取得するには、一度に1文字ずつOSに問い合わせる必要があり、非常に非効率的です。 POSIXシェルに組み込まれているreadは、一度に1バイトずつ取り出して行を非常に非効率的に読み込みます。

FILEストリームはOSからデータを要求しますが、効率は向上しますが、ファイル記述子は巻き戻し可能なファイルであればソケットやパイプでもかまいません。100文字を要求し、その100バッチの3文字目が改行文字であれば、それ以降の97文字の読み込みを元に戻す方法はありません。

+0

OSに一度に1つのcharを要求する必要はありません。一度に静的バッファを使用して一度に多くのバイトを取り出す単純な実装が可能ですあなたがOSから望むように。 これは実際に私が勉強した学校のコーディング練習、Epitech、get_next_lineと呼ばれていました。私はあなたがGitHubでその名前でたくさんの学生プロジェクトを見つけることができると確信しています。 これらのうちの1つを使用する場合は、一度に複数のファイルを処理できるように、ファイルディスクリプタを配列内に保持する必要があります。 – deb0ch

+1

@ deb0ch確かに。しかし、あなたは1行以上のものを読んだだけです。これは、次の場合にファイルへのアクセスがオフになることを意味します。a)バッファリング層を使用し続けるb)巻き戻し。そして、すべてのファイルが巻き戻し可能であるわけではないので、b)は常に可能ではありません。 – PSkocik

+0

はい、私はスタティックなバッファについて話していました。それは、後続のコールでそれを再利用し、新しいデータをフェッチする前にすでにバッファにある行を消費していたからです。おそらく、close()とopen()の間で信頼性を高めるためには、別のファイルに対して同じfdを与えるような作業が必要になるかもしれませんが、技術的には可能です。 – deb0ch

関連する問題