問題タブ [memory-layout]

一部のコンパイラでは、クラスに仮想関数がある場合、そのオブジェクトの最初のバイトのアドレスを使用してその vptr にアクセスできます。例えば、

さまざまなコンパイラの動作に依存していることはわかっています。一番最初のエントリとして vptr が格納される場合があるので、これを行う利点は何ですか? それはパフォーマンスの向上に役立ちますか、それとも単に &b を使用して vbtl にアクセスする方が簡単だからですか?

C アプリケーションのメモリ プロファイリングを行う必要があります。

フットプリントサイズとRAMサイズを含める必要があります...

たとえば、私のアプリケーションが以下のような場合..

出力：

したがって、フットプリントのプロファイリングで考慮すべきメモリと、プログラムがロードされるときの RAM ..

以下のプロファイリングは正しいですか？フットプリント メモリ = 760 (フラッシュまたはハードディスクを搭載) RAM = 67+8+0 = 75 バイト

専門家からの提案が必要

配列はメモリ内でどのように配置されますか?

実際のオブジェクトは並べて配置されますか

それとも、Java のように別の場所にオブジェクトが格納されたポインターの配列になりますか?

ヒープのどこかに：

また、make()メモリ内でスライスをどのようにレイアウトしますか?

Richard Powellによるこのcppcon トークに触発されて、次のコード スニペットを作成しました。

これは次のように出力されます:

に追加virtualした後who()、これを取得します

構造体に のサイズを追加するのvoid*は簡単ですが、非仮想の場合ではなく、仮想の場合にこのパディング (Richard の講演でも言及されています) があるのはなぜでしょうか?

Ubuntu 14.04 64ビットでgcc 5.3.0とclang 3.7.1でテストしました

Test オブジェクトのサイズは 8 バイトです。したがって、この例から、オブジェクトが 2 つの 4 バイトの _vptr で構成されていることが明らかです。継承の順序はpublic Base1,public Base2次のとおりであるため、オブジェクトは次のように作成する必要があります。

しかし、コード スニペットから、オブジェクトは次のように作成されているように見えます。

最初の vptr は、3 つの関数ポインター (1 番目のポイントBase1::fun1()、2 番目のポイント、Base1::func1()および 3 番目のポイント) の配列をポイントしTest::test()ます。

派生オブジェクトは、Base+Derived で構成されます。つまり、バイトの最初のチャンクが Base オブジェクトであり、残りが Derived であることを意味します。もしそうなら、私たちの objTest の例では、2 番目は 3 つの関数ポインタ (1 番目と、および)_vptrを指すはずです。しかし、代わりに、最初のが の関数ポインタを指していることがわかります。Base2::fun1()Base2::func1()Test::test()_vptrTest::test()

質問：

1.この動作はコンパイラ固有のものですか?

2.規格はこの動作について何か言及していますか? それとも私の理解は完全に間違っていますか？

私は iOS 用の Metal をいじって、ちょっとしたゲームを作っています。カーネル シェーダーの 1 つ (.metal ファイル内)。ゲーム プレイの一部のメタデータを保持する構造体を定義しています。

構造体は次のようになります。

これは完全に正常に機能しますが、構造体に次のようなフィールドを追加しようとすると:

コードが正しく動作せず、一部のフィールドを使用できないようです。この時点では、新しいフィールドは使用されていません。私の最初の考えは、構造体のメモリ配置に関係しているということでした。正しいパディングがコンパイラによって追加されるという印象を受けましたが、それでも先に進み、構造体のサイズを自分で適切に整列させようとしました (フィールドを降順で並べ替え、構造体を 48 バイトと 64 バイトに整列させました)。成功。また、アラインメントの問題を回避するためにパックされたデータ型を使用しようとしましたが、まだ成功していません。

構造体を使用せずに同じロジックを記述し、構造体を使用してまったく同じ動作でデータを保持するように移植したため、ロジックが正しいことはわかっています。しかし、この時点でフィールドを追加すると壊れます。また、元の構造体を維持しながらパックされたデータ型を使用すると、同様の方法で構造体が壊れます。

したがって、これは間違いなくメモリ レイアウトの問題のように思えますが、問題を回避せずに解決する方法がわかりません。

私が試すことができる考えやアイデアはありますか？

編集：

データは MTLBuffer を介してコンピューティング シェーダーに渡されませんが、.metal ファイルのインラインの定数メモリ空間で次のように定義されています。

編集2：

いくつかの調査結果と、コードが実際に行っていることを説明しようとしています。

ブレークする問題の関数は、この構造体で提供される値に基づいて色をフェードさせると想定されるメソッドです。

この関数は、構造体が次のように定義されている場合に期待どおりに機能します。

フロートを追加すると（どこにも読んでいなくても、計算の一部ではありません。これは、バグがどこにあるかを把握しようとするためです）。

この時点では、構築で新しいフロートを指定しなくても問題なく動作します。

しかし、私がこれを行うと：

上記の指定された機能が機能しなくなり、色が薄くなりません。

別の興味深い観察結果は、代わりに int を使用するとすべてが機能することです。

たとえば、アラインメントの可能性があるため、異なる型へのポインターを互いに直接変換することはできません (完全に正しいステートメントではないかもしれませんが、とにかく私の考えはわかりません)。次のようなことができないという同様の技術的な理由はありますか？

今すぐ私を削除して、この質問を編集して（奇妙なケースで）理解し、一般に翻訳してください。

D 仕様によると、すべてのクラスは参照によってアクセスされます。これは、次のクラスが次のようにメモリに配置されることを意味します。

擬似コード:

タイプ A のオブジェクトのメモリ レイアウト:

参照を持つ代わりに b を A に直接埋め込むクラスを作成する方法はありますか? それとも私は何かを見落としていますか？