C#で固定バイトまたはchar[100]をマネージドchar[]に変換する最良の方法は何ですか? 私はポインター演算を使用しなければならなくなったので、もっと簡単な方法があるかどうか疑問に思っています-memcpyまたは別の方法のようなものですか？

まず第一に、ブール型は4バイト値のデフォルトのマーシャル型を持っていると言われています。したがって、次のコードが機能します。

明らかに、これらの構造は独立してうまくマーシャリングします。値は期待どおりに変換されます。ただし、次のようにLayoutKind.Explicitを宣言して、これらの構造を「結合」に結合すると、次のようになります。

突然、これらのタイプを正しくマーシャリングできなくなったことがわかりました。上記の構造のテストコードとその失敗方法は次のとおりです。

この表現をtrueと見なすのは非常にユーモラスです：（a.bValue1！= false && a.bValue1 == true &&！true.Equals（a.bValue1））

もちろん、ここでのより大きな問題は、a.iValue2！= 4であり、4が1に変更されていることです（おそらくブール値が重複しているため）。

だから質問：これはバグですか、それとも設計どおりに失敗しただけですか？

背景：これ は、PInvokeを使用する場合のboolとuintを含む構造の違いは何ですか？

更新：ブール値に使用されるバイトのみが1に変更され、b.bValue2の0x0f00が0x0f01に変更されるため、大きな整数値（> 255）を使用する場合はさらに奇妙になります。上記のa.bValue1の場合、それはまったく変換されず、0x0f00はa.bValue1にfalse値を提供します。

アップデート＃2：

上記の問題に対する最も明白で合理的な解決策は、マーシャリングにuintを使用し、代わりにブールプロパティを公開することです。「回避策」で問題を実際に解決することは問題ではありません。これはバグなのか、それともあなたが期待する動作なのか、私はほとんど疑問に思っています。

重複していないフィールドが重複していると報告されている構造体があります。

報告されたエラーは次のとおりです。

タイプ「XXX」を読み込めませんでした...オフセット12にオブジェクトフィールドが含まれていますが、オブジェクトフィールドが正しく配置されていないか、オブジェクトフィールドと重なっています。

これは、リリース構成（TRACE、DEBUGフラグ、および安全でないコードが有効で、最適化がオフになっている）でのみ発生します。推測すると、どうなりますか？

UPD：@svickに感謝します。x64ビルドがマーシャリングに必要なものではないことを確認しました。

私は次のような構造を作成しました：

それから私は以下のコードでそれを読みました：

x86、x64、およびcortex armプロセッサではすべて問題ないのだろうかと思いますが、Atmel ARM9 AT91SAM9G20では、ushort変数の値が間違っています。たとえば、次の1番目と2番目のバイトの代わりに、次の1番目と3番目のバイトの値が置き換えられますが、バイト値の場合はすべて問題ありません。

質問

別の( )であるフィールドを持つSAを使用して、構造体 ( ) を構築しようとしました。[StructLayout(LayoutKind.Explicit)]structSB

最初[StructLayout(LayoutKind.Explicit)]: 他の構造体を なしで宣言できることに驚きましたが、SAでは、すべてのフィールドにが必要[FieldOffset(0)]です。あまり意味がありません。

• これはコンパイラの警告/エラーの抜け穴ですか?

2 番目: のすべての参照 ( object) フィールドSBが の前に移動されているようですSB。

• この動作はどこかで説明されていますか?
• 実装依存ですか？
• 実装に依存しているとどこかで定義されていますか?:)

注：これを本番コードで使用するつもりはありません。私は主に好奇心からこの質問をします。

実験

このコードを実行すると:

x86 と x64 の両方でこの出力が期待されます:
4 または 8 (x86 または x64 に応じて)

2
3
1
6
0
4
5
ゴミ

x86で代わりに得られるもの:
4

6
0
2
3
1
4
5
ゴミ

x64で代わりに得られるもの:
8

6
0
2
3
1
0
4
5

詳細:
- LayoutKind.Explicit および FieldOffset 属性を削除すると、問題は解決します。
- Bool フィールドを削除すると、問題が解決します。
- Long フィールドを削除すると、問題が解決します。
- x64 では、Pack=4 属性パラメーターも無視されているように見えることに注意してください。

これは、.Net3.5 および .Net4.0 にも適用されます。

私の質問：何が欠けていますか？それともこれはバグですか？
同様の質問を見つけました:
構造体に DateTime フィールドが含まれている場合、LayoutKind.Sequential の動作が異なるのはなぜですか?
しかし、私の場合、サブ構造体の属性が変更されても、データ型を変更せずにレイアウトが変更されます。したがって、最適化のようには見えません。それに加えて、他の質問がまだ答えられていないことを指摘したいと思います。
その他の質問では、マーシャリングを使用するときにレイアウトが尊重されると述べています。私はそれを自分でテストしていませんが、関連するすべての属性が適切に配置されているように見えるのに、安全でないコードに対してレイアウトが尊重されないのはなぜでしょうか? マーシャリングが行われない限り、これらの属性は無視されるとドキュメントのどこかに記載されていますか? なんで？
これを考慮すると、安全でないコードに対して LayoutKind.Explicit が確実に機能することを期待できますか?
さらに、ドキュメントには、構造体を予想されるレイアウトで保持する動機について言及されています。

Auto 値に関連するレイアウト関連の問題を軽減するために、C#、Visual Basic、および C++ コンパイラは、値の型に Sequential レイアウトを指定します。

しかし、この動機はアンセーフ コードには当てはまらないようです。

ポインターを使用してデータのブロックに対して XOR を実行するコードがありますが、これは高速ですが、アセンブリの「安全でない」要件を取り除きたいと考えています。LayoutKind.Explicit を使用するように変更し、「ulong[]」を「byte[]」の上に重ねると、基本的にはポインターで行ったのと同じことをしていますが、同じように危険なようです。これら 2 つの主な違いは、「安全」バージョンの速度が「安全でない」バージョンの約 1/2 であることです。

これは「安全でない」アセンブリを回避するための正当な方法ですか、それとも一度に 1 バイトずつ byte[] にアクセスすることが安全な方法でこれを行う唯一の正当な方法ですか?

次のコードを使用すると、 「オブジェクト以外のフィールドが正しく配置されていないか、重なり合っています」というエラーが発生します。

System.Runtime.InteropServicesとLayoutKind.Explicitを使用してユニオンを実装しました。

問題はstructのstringにあると思います。この問題を解決するにはどうすればよいですか?