3

私はバイナリファイルリーダー/ライターを書いていますが、エンディアンの問題を処理するために、すべてのデータを書き込み時に「ネットワーク」(ビッグ) エンディアンに変換し、読み取り時にホストエンディアンに変換することにしました。hton*それらの機能だけのためにwinsockとリンクしたくないので避けています。

私の混乱の主なポイントは、浮動小数点値の処理方法にあります。すべての整数値について、<cstdint>(uint32_tなど) でサイズ指定された型を使用していますが、私の調査では、浮動小数点型に相当するものは存在しません。書き込み時にすべての浮動小数点値を 32 ビット表現に変換し、ホストで使用されている精度に戻します (私のアプリケーションでは 32 ビットで十分です)。このようにして、浮動小数点値に対して読み書きするバイト数を正確に知ることができます。ファイルをロードしているマシンと、ファイルを書き込んだマシンで使用sizeof(float)して異なっていた場合とは対照的です。sizeof(float)

frexpを使用して仮数と指数を整数項で取得し、それらの整数を (固定サイズで) 書き出し、次に整数を読み取り、 を使用して浮動小数点値を再構築する可能性を認識しましldexpた。これは有望に見えますが、/なしで float エンディアンを処理するための一般的に受け入れられている、または推奨されている方法があるかどうか疑問に思っていhtonfntohfます。

私がターゲットとするプラットフォームはほぼ確実floatに 32 ビットで表現されることはわかっていますが、将来のプロジェクトで使用できるように、現在記述しているコードを可能な限り互換性のあるものにしたいと考えています。

4

1 に答える 1

2

完全にクロスプラットフォームで標準に準拠したい場合は、frexp/ldexpソリューションが最適な方法です。(ただし、ソース ハードウェアまたはターゲット ハードウェアのいずれかが 10 進浮動小数点を使用する非常に理論的なケースを考慮する必要があるかもしれません。)

いずれかのマシンが 32 ビット浮動小数点表現を持っていなかったとします。その場合、エンディアンに関係なく、そのマシンには 32 ビット浮動小数点数とビット互換のデータ型はありません。そのため、非 32 ビット浮動小数点数を送信可能な 32 ビット表現に変換したり、送信された 32 ビット表現をネイティブの非 32 ビット浮動小数点数に変換したりする標準的な方法はありません。

スコープを 32 ビットの浮動小数点表現を持つマシンに限定することもできますが、両方のマシンが符号、指数、および仮数専用のビットの数と順序が同じであると想定する必要があります。最近は IEEE-754 フォーマットがほぼ普遍的になっているため、これが当てはまる可能性がありますが、C++ はそれを主張しておらず、少なくとも 1/8/23 ビットの浮動小数点数を上位端の代わりに下位端の符号ビット。

つまり、エンディアンは、2 進浮動小数点形式間で起こりうる非互換性の 1 つにすぎません。ただし、すべての浮動小数点数を 2 つの整数に減らすと、他の非互換性 (基数以外) に対処する必要がなくなります。

于 2014-03-30T04:09:28.400 に答える