問題タブ [iostream]

私は C++ 開発者で、最近まで Windows 向けのアプリケーションの作成を余儀なくされるまで、主に Solaris と Linux でプログラミングを行っていました。

私は、TCP ソケットに支えられた C++ I/O ストリームに基づく通信設計を使用してきました。この設計は、他のスレッドが同じストリームを介して送信する (mutex によって同期される) 間、ストリームから継続的に読み取る単一のスレッド (ほとんどの場合、データを待機するソケット読み取りでブロックされる) に基づいています。

Windows に移行するとき、boost::asio::ip::tcp::iostream を使用してソケット ストリームを実装することにしました。上記のマルチスレッド設計により、Windows でデッドロックが発生したことを知り、がっかりしました。はoperator<<(std::basic_ostream<...>,std::basic_string<...>)、入力操作と出力操作の両方でストリーム全体をロックする「Sentry」を宣言しているようです。読み取りスレッドは常にストリームを待機しているため、この Sentry が作成されると、他のスレッドからの送信操作がデッドロックします。

operator<< と Sentry の構築中のコール スタックの関連部分を次に示します。

istream コンポーネントと ostream コンポーネントが別々にロックされていれば問題ありませんが、そうではありません。

使用できるストリーム演算子の代替実装はありますか? ロックしないように指示できますか？自分で実装する必要がありますか (これを行う方法がわからない)。

任意の提案をいただければ幸いです。

(プラットフォームは Windows 32 ビットおよび 64 ビットです。Visual Studio 2003 Pro および 2008 Express で観察された動作)

私はiostreamのバイナリバージョンを書いています。基本的に、バイナリ ファイルを書き込むことができますが、ファイルの形式を細かく制御できます。使用例:

my_int を符号なし 32 ビット整数として書き込み、my_string を長さのプレフィックス付き文字列 (プレフィックスは u16le) として書き込みます。ファイルを読み戻すには、矢印を反転させます。よく働く。しかし、私はデザインに問題があり、それについてはまだ迷っています。だから、SOに尋ねる時が来ました。(現時点では、8 ビット バイト、2 の補数の整数、IEEE 浮動小数点数など、いくつかの仮定を立てています。)

内部では、iostream は streambuf を使用します。これは実に素晴らしい設計です。iostreams は ' int' をテキストにシリアライズするコードを作成し、基になる streambuf に残りを処理させます。したがって、cout、fstream、stringstream などを取得します。これらはすべて、iostream と streambuf の両方で、通常は char でテンプレート化されますが、wchar としてテンプレート化されることもあります。ただし、私のデータはバイト ストリームであり、' unsigned char' で表すのが最適です。

私の最初の試みは、に基づいてクラスをテンプレート化することでしたunsigned char。std::basic_stringテンプレートで十分ですが、そうでstreambufはありません。という名前のクラスでいくつかの問題に遭遇しましたが、これはテーマcodecvtに従うことができませんでした。unsigned charこれにより、次の 2 つの疑問が生じます。

1)なぜストリームバッファがそのようなことをするのですか? コード変換は、ストリームバッファの責任から外れているようです-ストリームバッファはストリームを取り、それとの間でデータをバッファリングする必要があります。これ以上何もない。コード変換と同じくらい高レベルなものは、iostream に属するべきだと感じます。

テンプレート化されたストリームバッファを unsigned char で動作させることができなかったので、char に戻り、単に char/unsigned char の間でデータをキャストしました。明らかな理由から、キャストの数を最小限に抑えようとしました。ほとんどのデータは、基本的に read() または write() 関数にまとめられ、その後、基になる streambuf が呼び出されます。（そして、プロセスでキャストを使用します。）読み取り関数は基本的に次のとおりです。

良い解決策、悪い解決策?

最初の 2 つの質問は、さらに情報が必要であることを示しています。最初に、boost::serialization などのプロジェクトが検討されましたが、それらは独自のバイナリ形式を定義するという点で、より高いレベルに存在します。これは、形式を定義する必要がある場合、または形式が既に定義されている場合、または一括メタデータが不要または不要な場合に、より低いレベルで読み取り/書き込みを行うためのものです。

binary::u32le第二に、修飾子について質問する人もいます。これは、現時点では必要なエンディアンと幅を保持するクラスのインスタンス化であり、将来的には符号付きになる可能性があります。ストリームは、そのクラスの最後に渡されたインスタンスのコピーを保持し、それをシリアル化で使用しました。これはちょっとした回避策でした。最初は << 演算子を次のようにオーバーロードしようとしました。

しかし、当時、これはうまくいかなかったようです。あいまいな関数呼び出しでいくつかの問題がありました。これは特に定数に当てはまりますが、あるポスターが示唆したように、キャストするか、単に . として宣言することもできconst <type>ます。しかし、他にも大きな問題があったことを覚えているようです。

エラーに関して標準ストリームのようにカスタム ストリームを機能させることは可能ですか? デフォルトでは、例外ではなく、good/fail/bad/eof ビットを使用しますか?

ブースト ドキュメントでは、ストリーム エラーに対して std::failure をスローし、他のエラーを伝播させることについてのみ言及しています (たとえば、バッファーを割り当てようとすることによる badalloc)。ただし、ブースト コードはこれらをキャッチしていないようで、代わりにユーザー コードの処理に依存しています。それらですが、私の既存のコードはすべて、エラー後に再試行する必要がある場合に備えて、good()、bad() などのメソッドと clear() メソッドに依存しています。

これを行うにはどうすればよいでしょうか？また、簡単にできる方法はありますか？Boostなどのライブラリを使用していますか？

URLからSystem.IO.Streamオブジェクトに読み込もうとしています。使ってみました

しかし、URI形式がFileStreamオブジェクトでサポートされていないというエラーが表示されます。URLから読み取ることができるSystem.IO.Streamから継承する使用できるメソッドはありますか？

ストリームを介して 2 つのライブラリをブリッジする必要があります。

そして、このような別のライブラリからのいくつかの関数

QDataStream の作成方法を制御することはできず、read_somthing 関数のインターフェイスを変更することはできません。

最初に考えられるのは、istream を継承して QDataStream をラップするクラスを作成することです。誰もそれをやったことがありますか？

私が考えたことが適切な方法ではなかった場合、それを達成するための最良の方法は何だろうか.

Asioで2 つのストリーム指向の I/O オブジェクトが与えられた場合、一方のデバイスから他方のデバイスに双方向でデータを転送する最も簡単な方法は何ですか? これは、おそらくboost ::iostreams::combinationまたはboost::iostreams:copyで行うことができますか? それとも、両端でデータを待ってから、もう一方のストリームに書き出す手動のアプローチの方がよいでしょうか? 言い換えれば、BoostとAsioを活用して最小量のコードを生成するにはどうすればよいでしょうか?

サンプル アプリケーションは、この質問で要求されているように、シリアル ポートと TCP ソケットの間でストリーミングします。

ファイルを開いてバイナリデータをファイルに追加するレガシーコードに取り組んでいます。

何らかの理由で、コードはファイルを 2 回開きます。これは、Windows でファイルをロックするために _sopen が使用されているためですか?

もしそうなら、どうして std::ifstream::open がファイルをロックしないのでしょうか?

Windows ファイル ハンドルが既に閉じられているかどうかを確認する方法はありますか?

私はいつも読んでいて、バイナリファイルを扱うときは、フォーマットされたデータで使用するためのものであるため、 << および >> 演算子ではなく read() および write() を使用する必要があると言われています。それらを使用できることも読みましたが、それは高度なトピックであり、誰も飛び込んで議論している場所を見つけることができません。

最近、次のことを行うコードを見ました。

バイナリ ファイルでの << 演算子の使用を指摘したとき、rdbuf() 呼び出しは streambuf * を返し、 << は streambuf* をオーバーロードし、書式設定なしで直接コピーを行うので安全であると言われました。

これは真実で安全ですか？効率はどうですか？落とし穴はありますか？詳細をいただければ幸いです。

ありがとう！

次のようなことができるように、C++ での I/O ストリームの書式設定の効果を範囲制限したいと思います。

ベース、精度、塗りつぶしなどは、ブロックを離れるときに以前の値に復元されます。

これが私が思いついた最高のものです：

...しかし、C++ iostream はかなり厄介な領域であり、上記の安全性/適切性については確信が持てません。それは危険ですか？あなた（またはサードパーティ）はすでにより良い結果を出していますか？