0

メモリバッファをとして扱うクロスプラットフォームの方法が必要ですFILE*。これを行うための移植可能な方法がないことを指摘する他の質問を見ました（Linuxのfmemopenは私が必要とするものですが、Windowsプラットフォームでは失敗します）。

setvbufを使ってみましたが、うまくいくようです。setvbuf関数を使用する際の正確な問題を誰かが指摘できますか？

また、私はC標準ドラフトWG14 /N1256と7.19.5.6が言うのを見ました：

配列の内容はいつでも不確定です。

自分のバッファを使用するかどうかわかりませんが、その内容をどのように不確定にすることができますか？

編集：すべての答えをありがとう。この方法はもう使用していません。

4

3 に答える 3

2

いいえ、これを行うためのポータブルな方法はありません。

使用は機能しているように見えるsetvbufかもしれませんが、実際には未定義の動作を呼び出しており、予期しないときに予期しない方法で失敗します。ご指摘のとおり、 GNU Cライブラリには拡張機能がありますが、GNU以外のシステムには移植できません。fmemopen(3)

ポインタを必要とするライブラリを使用していFILE*て、メモリに必要なデータしかない場合は、それを一時ファイルに書き出して、そのファイルへのハンドルを渡すだけです。理想的には、ライブラリはファイルポインタの代わりにメモリポインタを使用する代替関数を提供する必要がありますが、そうでない場合は運が悪いです（そして、その欠陥についてライブラリの作成者に文句を言う必要があります）。

于 2012-09-19T18:14:29.190 に答える
1

関数setvbuf()はFILE、メモリをバッファとして使用するように指示するために使用されますが、このメモリがどのように使用されるかを指定するものではありません。これは実装次第です。

したがって、バッファの内容はいつでも不確定であり、それがあなたのために機能する場合、それは偶然です。

于 2012-09-19T18:15:11.877 に答える
1

バッファ/ファイル*で何をしたいかによります。確かに簡単な操作を実行してそれらを回避することはできますが、すべてのFILE*操作がメモリバッファーで期待どおりに実行されることを保証することはできません。

申し訳ありませんが、完全なFILE *特性を取得するためのクロスプラットフォームのワンライナーはありません。私は何度も自分自身を試しましたが、

お手並みをみせてもらおう：

  • ＃define-wrappedOS固有のロジック
  • 対話しようとしているインターフェースをさらに調べてください。ある時点で、とにかくバッファで再生するだけです。次に、バッファを接続します。これが私がしたことです。
  • あなたのテクニック+信仰。
于 2012-09-19T18:15:29.263 に答える