問題タブ [allocator]

次のコードが segfaults になる明白な理由はありますか?

ありがとう

編集: Linux/i686 で g++ 4.5.0 を使用しています。ここで何をしているのかわからないかもしれませんが、次の segfaults でさえ

私はそれがアライメントの問題であるに違いないと本当に思います。

STL コンテナーで TCMalloc を使用したいので、TCMalloc で構築されたアロケーターが必要です (TBB malloc での tbb_allocator など)。TCMalloc のドキュメントが見つかりません(ドキュメントと呼ばれる場合)。そこで、ヘッダー ファイルの調査を開始し、 というクラスを見つけましたSTL_Allocator。しかし、何かがはっきりしません。stl_allocator.h からの引用:

STL_Allocator テンプレート クラスの定義は次のとおりです。

Allocその議論が何であるかはわかりません。一部のメモリ割り当て関数のラッパー クラスを作成する必要がありますか? TCMallocを使った人はいますか？

std::vector< nIcon*> クラスの c++ アロケータを作成するのを手伝ってください。

私が見つけたすべての例は、コード例ではなく、上書きする必要があるメソッドだけを示しています。

ウィンドウで共有メモリを使用してアロケーターを実装する必要があります (CreateFileMapping と MapViewOfFile を使用)。

私はMSVC9.0を搭載したWindows7でC++を使用しており、MSVC9.0を搭載したWindowsXPSP3でテストおよび再現することもできました。

0.5MBサイズのオブジェクトを1GB割り当てた場合、それらを削除すると、すべて問題なく動作し、期待どおりに動作します。ただし、0.25MBサイズのオブジェクトを削除するときに1GBを割り当てると、メモリは予約されたままになり（アドレス空間モニターでは黄色）、それ以降は0.25MB未満の割り当てにのみ使用できます。

この単純なコードでは、typedefする構造体を変更することで両方のシナリオをテストできます。構造体を割り当てて削除した後、1GBの1MB charバッファーを割り当てて、charバッファーが構造体がかつて占有していたメモリを使用するかどうかを確認します。

以下に、アドレス空間モニター内からの私の結果を示します。これら2つの最終結果の唯一の違いは、1GBマーカーまで割り当てられる構造体のサイズであることを強調しておきます。

これは私には非常に深刻な問題のように思えます。多くの人が苦しんでいて、それを知らない可能性もあります。

• それで、これは設計によるものですか、それともこれはバグと見なされるべきですか？
• 小さな削除されたオブジェクトを、より大きな割り当てで実際に無料で使用できるようにすることはできますか？
• そして、好奇心から、MacまたはLinuxマシンも同じ問題に苦しんでいますか？

四分木疎行列クラスを作成しようとしています。つまり、aquadtree_matrix<T>はゼロ行列または の 4 倍(ne, nw, se, sw)ですquadtree_matrix<T>。

これはおそらく線形代数演算のパフォーマンスに影響を与えるため、最終的にはさまざまな割り当てスキームをテストしたいと思います。quadtree_matrixしたがって、既存のアロケーターを再利用できるように、標準のアロケーターの型もテンプレート化します。

2 つの異なる種類のデータを割り当てる必要があります: a T、または a のいずれかで、 node4 つのポインター (T またはノードへの) を含みます。私が検討するすべてのアルゴリズムについて、アルゴリズムの任意の時点で直面している部分行列のサイズが何であるかを知っているため、どのような種類のデータが期待されるかを確実に知っています (これらのサイズを保存する必要さえありません)。

もちろん、2 つの異なるアロケーターを使用します。アロケーターの型はテンプレートとテンプレートのコピー コンストラクターを提供するため(標準コンテナーのメンバーがコピーを返すことで提案するrebindように、値の型として使用することを意図しています)、これで問題ありません。get_allocator

問題は、アロケーター メンバー関数が特定のpointer型を使用することです。これはバニラ ポインターである必要はありません。一部のアロケータ (ブースト インタープロセス アロケータ) は、この機能を広範に使用します。

アロケーター ポインターの型がさまざまなポインターである場合、問題はありません。少なくとも、ポインターを使用して void を指定し、それらを正しい型 ( または のいずれnode*かT*) に再解釈_キャストすることができます。ユニオンを使用することもできます（おそらくより良いでしょう）。

私の知る限り、allocator::pointer型の PODness に関する要件はありません。これらは、ランダム アクセス イテレータである必要があるだけです。

さて、私の質問は次のとおりです。

アロケータ クラス テンプレートA<T>(またはそれに相当するものA::rebind<T>::other) が与えられた場合、次のことが保証されますか。

1. 提供された静的キャストの機能A<T>::pointerは、 ?のアクセス可能なベースです。A<U>::pointerUT
2. 提供された静的キャストの機能A<T>::pointerはアクセス可能なベースであり、キャストの「ランタイム型」(このコンテキストでこれが意味するものは何でも) は?A<U>::pointerTUU
3. タイプA<void>::pointer（これが理にかなっている場合）？

それとも、私が考えもしなかった問題の解決策はありますか?

これらのバージョンのnewとdeleteは例外セーフですか? 考えられる落とし穴はありますか？

Customized_allocator_typeが STL 互換であると仮定します。また、アロケーターのコンストラクターには副作用がなく、すべてのインスタンスが同等であると仮定します。

ご意見をお寄せいただきありがとうございます。

現在、リンクされたリストやグラフのように自分自身を指す ノードを持つ複雑なクラスを変更しています。boost::interprocess関数を使用して共有メモリで使用したい。現在、汎用性を保ち、変更が最小限になるように再設計する方法を探しています。

再設計では、 boost ::interprocess::offset_ptr型の相対スマート ポインターを暗黙的に使用するために、 boost::interprocess ::allocatorアロケーターを使用する必要があります。次のような2番目のテンプレートパラメーターを含める必要があると思いました

もちろん、参照の場合と同様に、循環依存関係のために機能しません。
それを実装する最善の方法について、C++ クラス テンプレートの専門家から助けを得られることを願っています。ブースト共有メモリ対応のコンテナーを見てみましたが、いくつかの外部クラスが関与するかなり複雑な方法で解決しています。

ジョー

C ++ Primer第4版、755ページによると、次のようなメモがあります。

最近のC++プログラムでは、通常、アロケータクラスを使用してメモリを割り当てる必要があります。より安全で柔軟性があります。

私はこの声明をよく理解していません。newこれまでのところ、私が読んだすべての資料は、C++でメモリを割り当てるために使用する方法を教えています。ベクトルクラスがアロケータをどのように利用するかの例は、本に示されています。しかし、他のシナリオは考えられません。

誰かがこの声明を明確にするのを手伝ってもらえますか？もっと例を教えてください。アロケータはいつ使用する必要がありますnewか？ありがとう！

私は Visual Studio 2008 C++ アプリケーションを使用しており、std::vector. しかし、私は問題に遭遇しました。私の実装は、リソースへのハンドルを所有するアロケータに依存しています。この機能を使用する場合rebind、ハンドルの所有権を新しいアロケーターに譲渡する必要があります。このようなもの：

残念ながら、古いアロケーターのハンドル所有権を解放することはできませんconst。rebind コンストラクターから削除するconstと、コンテナーはそれを受け入れません。

この問題を回避する良い方法はありますか?

Visual Studio 2008 C ++アプリケーションがあり、標準コンテナーにカスタムアロケータを使用して、メモリがヒープではなくメモリマップトファイルから取得されるようにしています。このアロケータは、4つの異なるユースケースで使用されます。

1. 104バイトの固定サイズ構造std::vector< SomeType, MyAllocator< SomeType > > foo;
2. 200バイトの固定サイズ構造
3. 304バイトの固定サイズ構造
4. nバイトの文字列std::basic_string< char, std::char_traits< char >, MyAllocator< char > > strn;

これらのそれぞれに合計約32MBを割り当てることができる必要があります。

std::mapアロケータは、割り当てサイズへのポインタを使用してメモリ使用量を追跡します。typedef std::map< void*, size_t > SuperBlock;各スーパーブロックは4MBのメモリを表します。

std::vector< SuperBlock >1つのSuperBlockに十分なスペースがない場合に備えて、これらがあります。

アロケータに使用されるアルゴリズムは次のようになります。

1. スーパーブロックごとに：スーパーブロックの最後にスペースはありますか？そこに割り当てを置きます。（速い）
2. そうでない場合は、各SuperBlock内で十分なサイズの空きスペースを検索し、そこに割り当てを配置します。（スロー）
3. まだ何もありませんか？別のSuperBlockを割り当て、その割り当てを新しいSuperBlockの先頭に配置します。

残念ながら、ステップ2はしばらくすると非常に遅くなる可能性があります。オブジェクトのコピーが作成され、一時変数が破棄されると、多くの断片化が発生します。これにより、メモリ構造内で多くの詳細な検索が発生します。使用できるメモリの量が限られているため、断片化が問題になっています（下記の注を参照）

プロセスをスピードアップするこのアルゴリズムの改善を誰かが提案できますか？2つの別々のアルゴリズム（1つは固定サイズの割り当て用、もう1つは文字列アロケータ用）が必要ですか？

注：理由が必要な場合：ヒープに32MBのプロセススロット制限があるWindowsMo​​bileでこのアルゴリズムを使用しています。だから、いつもstd::allocatorはそれをカットしません。十分なスペースを確保するために、1GBの大容量メモリ領域に割り当てを配置する必要があります。