問題タブ [offsetof]

構造体のメンバーのオフセットを取得したい。これが何度も尋ねられたことは知っていますが、答えは常に強力なoffsetofです。私の場合は少し異なります。不明な型のオフセットが必要です。たとえば、次のとおりです。

不明からわかる唯一のことは、型が設定されている順序です。すなわち

そして、ここでの主な問題は、整列/パディングです。これを計算する方法も、方法があるかどうかもわからないためです。

この種の質問には、次のように答えることがよくあります。

それらの人々のために: 私は C++ で JSON パーサーを実装していて、(複数の型の配列を表す) 問題に直面しました。私の解決策は、配列の値をカスタム構造体にマップすることです。

私はその解決策に関するフィードバックを受け入れますが、主に質問への回答に関心があります

クラスがis_standard_layoutの場合、特定の非静的データ メンバーがオブジェクトのアドレスから常に同じオフセットを持つことを保証するのに十分ですか (つまり、そのクラスの異なるインスタンス間でプロセス全体で同じ)?

ここに「GetParent()」関数を実装したいと思います-

親オブジェクトへのポインターを格納するプライベート メンバー変数を作成しようとしました。ただし、この方法には追加のメモリが必要です。

そこで、offsetof() マクロを使用しました (offsetof() を呼び出すパフォーマンス コストは無視できます) が、このアプローチが安全かどうかはわかりません。あらゆる状況で機能しますか？より良いアイデアはありますか？

のマクロoffsetofを<cstddef>見ていて、可能な実装が経由であることがわかりました

私はそれを試してみましたが、実際には期待どおりに動作します

Live on Coliru

私が行った唯一の変更は、アドレスをポインターとして表示したいので、void*の代わりに最終キャストを使用することです。size_t

私の質問:

1. コードは完全に合法ですか。つまり、 を介してメンバーに「アクセス」し、nullptrそのアドレスを取得することは合法ですか? そうであれば&(((type*)nullptr)->member)、メンバーのアドレスを 0 から相対的に計算しているように見えますが、これは本当ですか? (最後の 3 行で のアドレスに対するオフセットを取得しているようですs)。
2. マクロ定義から最後のキャストを削除すると(void*)、segfault が発生します。なんで？&(((type*)nullptr)->member)type のポインターであってはなりませんかtype*、またはここで型が何らかの形で消去されていますか?

私は、offsetof MACRO の実装の説明について、非常に長く懸命に検索してきました (リンクは最後に)。

特に、構造体のメンバーのオフセットを取得するための NULL の逆参照。多くの記事では、NULL ポインターは実際には実際には逆参照されないと言ってその理由をごまかしていますが、それは私には意味がありません。

ここに私が理解しようとしたリンクのいくつかがあります：

1. http://www.viva64.com/en/b/0301/
2. http://www.embedded.com/design/prototyping-and-development/4024941/Learn-a-new-trick-with-the-offsetof--マクロ
3. http://www.geeksforgeeks.org/the-offsetof-macro/
4. C の offsetof マクロはどのように機能しますか?
5. NULL ポインターを逆参照すると、C/C++ でプログラムがクラッシュすることが保証されますか?

私が探して理解しようとしているのは、コンパイラが MACRO 定義をどのように解釈するかを段階的に理解することです。最終的には、NULL ポインターが実際に逆参照されていない方法を説明します。

編集:他の質問が私の質問に答えたとしても、元の投稿で指摘されているように、それらは私には意味がありません。@dasblinkenlight による回答は、他の質問への回答で私が抱えていた正確な問題、つまり、実際にポインターを逆参照していないのはどうしてなのかを明らかにしています。

構造体があり、オフセットをメンバーに抽出するとします。

struct A標準に準拠した方法でメンバーを抽出するためのポインターが与えられた場合、どうすればよいですか? もちろん、正しいオフセットと正しいオフセットがあると仮定しstruct A*ます。1 つの試みは、次のようなことです。

これはおそらく機能しますが、たとえば、ポインターが同じ配列のポインター (または末尾を過ぎたポインター) である場合にのみ、ポインター演算が標準で定義されているように見えることに注意してください。これは事実である必要はありません。技術的には、その構造は未定義の動作に依存しているように見えます。

別のアプローチは

これもおそらく機能intptr_tしますが、存在する必要はなく、私が知る限り、算術演算でintptr_t正しい結果が得られる必要はないことに注意してください(たとえば、一部のCPUには、バイト境界で整列されていないアドレスを処理する機能があることを思い出します。配列内のintptr_tそれぞれについて 8 ずつ増加することを示唆しています)。char

標準で忘れられているもの (または私が見逃したもの) があるようです。

組み込みプログラミングでは、ハードウェアを記述するときに、ハードウェア エンジニアが設計した既知の事前定義された位置に構造体要素を配置する必要があることがよくあります。たとえば、次の単純化された例のように、約 100 のレジスタ/領域を持つ構造 FPGA を定義してみましょう。

今、私は手計算と、構造が変化した場合のエラーの可能性にイライラし、怒っています。これをより堅牢/便利にする方法はありますか? 私はそれをこのように書いてみました：

しかし、これは不完全な構造体について不平を言ってコンパイルしません...私の例は単純化されていることに注意してください。実際には、定義しなければならない予備フィールドが 20 ～ 30 あります。構造は非常に大きいです。