問題タブ [allocator]

ここでは、例外仕様によるものと言われています。私はこれを理解できません。この質問は例外仕様と関係がありますか？

C++のアロケータがvoid型に特化していることに気づきました。これを行う特別な目的はありますか？voidタイプにメモリを割り当てるのは意味がありませんよね？

std::scoped_allocator_adaptorこれまでに gcc 4.7.0 で実装された C++11 を試しているときに、C++11 FDIS はstd::uses_allocatorタプル ( 20.4.2.8[tuple.traits]) の特殊化を定義しているが、ペアには定義していないことに気付きました。タプルと同じです ( 、 などの特殊化がありstd::getますstd::tuple_size)。

さらに読むと、これらのことを紹介したN2554allocator_argでは、ペアのコンストラクターとuses_allocator特殊化も定義されています (23-24 ページ)。

なぜ彼らはペアで落とされたのですか？私が見ることができないそれらを使用する別の方法はありますか、またはこれはタプルを支持するペアの非推奨のヒントですか?

私のテストコードは次のとおりです。

boost::interprocess::managed_shared_memory セグメントに boost::unordered_map を作成しようとしています。これは、boost::interprocess::allocator を使用してから boost::interprocess::cached_node_allocator に変更しようとするまでは問題なく動作します。

hash_bucket 構造がキー サイズの計算を遅らせているようですが、cached_node_allocator はコンパイル時にサイズが必要です。これを機能させる方法についてのアイデアはありますか？

サンプルコード:

GCC 出力:

allocator代わりにoperator new直接operator delete使用するように改造しているコードがいくつかあります。このコードのパブリックインターフェイスの一部は、ハゲポインターではなく、shared_ptr（ハゲポインターから構築されて）を返すことですnew。

pointerアロケータの公開契約には、、などの名前のいくつかのtypedefがありますconst_reference。アイデアは、型T *を直接参照する代わりに、を使用pointerして、アロケータの作成者がCポインタ以外のものを挿入できるようにすることです。

しかし、私は今度は通常のポインターをスマートポインターでラップしています。これは、正直なCポインターを必要とします（私は思います）。コードをアロケーターのtypedefを使用するように変更しようとすると、問題が発生しますか？私はまだ試していません（試すためだけにやるべき足の仕事が少しあるので）ので、私は最初に尋ねています。

編集：これが私が変更したいコードのいくつかです（それはあまり友好的ではないので、私は最初は含めませんでした）。

特に、式の結果で呼び出されるconstructand destroytemplateメソッドは、現在、とinitializer(injector)の直接使用を埋め込んでいます。代わりに使用して、新しい/明示的な破棄の配置に切り替えて、次のようなものを作成したいと思います。newdeleteAllocator

問題は、アロケータのtypedefを尊重する必要があるかどうかです。私はそうあるべきであるか、そうでなければアロケータを正しく使用していないようです（実際的に言えば、それらのほとんどすべてが「退屈な」typedef値を持っていることを気にしないでください）。

私はそれをに押し込もうとするまで、確かにそれをジガーして、Allocator::pointerの代わりに戻すことができます。そして多分それはそこでも機能しますか？それが私の質問です。おそらく、私よりも標準に精通している人は、「のような偽医療があり、カスタム削除機能を登録している限り、問題はない」と言うことができます。Impl *shared_ptrAllocator::pointeroperator*

編集： @bdonlanは、aがではなく、でshared_ptrあるものにテンプレート化されているという優れた点を提起します。代わりに、おそらく内部的に保持されます。これは、アロケータの作成者が、変換された値を使用する場合でも、具体的に述べられたセマンティクスに従って「すべてうまくいく」ように実装することを選択する可能性があることを除いて、質問に答えるようです。Allocator::value_typeAllocator::pointerAllocator::value_type *operator Allocator::value_type *Allocator::pointer

標準では、アロケータの作成者がこれを行う必要がありますか？

編集：関連を参照してください。

次のようなカスタムメモリアロケータを作成します。

このアロケータの目的は、異なるコンテナによって割り当てられたメモリを共有し、すべてのコンテナが削除された場合にのみそれらの割り当てを解除することです。したがって、私はを使用しますboost::shared_ptr。

しかし、VS2008で実行した後、メモリリークを検出しました。どうしてか分かりません。

に変更boost::shared_ptrするMemoryChunksと、メモリリークがなくなります。

全て

カスタムアロケータのコードがあります。これは、他のアロケータのプロキシとして、たとえば割り当て統計などを収集できるようにすることを目的として作成されています。

このアロケータを以下のように使うと

以下のようなエラーが発生します

なぜそれが起こるのですか？再バインド構造と再バインドコピーコンストラクターの両方がありますが、何が問題になっていますか？

よろしくお願いします、Andriy

mlock(2)を呼び出して STL コンテナーのコンテンツがディスクにスワップされるのを防ぐアロケーターを見た人はいますか?

このようなアロケーターを作成するには、1 つだけトリッキーな部分があります。つまり、mlock される割り当てをクラスター化することによって、mlock されるページの数を最小限に抑えます。エルゴ、共有メモリアロケータを変更することから始めるべきでしょうか?

私の STL コンテナのメモリ使用量は変動しやすいと予測されています。つまり、頻繁に縮小したり拡大したりします。STLコンテナの型宣言にアロケータを指定することで、これを説明しようと考えています。プール アロケーターがこの種の状況に対処するためのものであることは理解していますが、私の懸念は、ボラティリティがプールが説明する以上のものになることです。それを克服するには、適切なプール メトリックを決定するために多くのテストを行う必要があります。

私の理想的なアロケーターは暗黙のうちに memoryを解放することはありません。実際、アロケーターが破棄されたときにのみメモリが解放される場合は、完全に受け入れられます。未使用のメモリを明示的に解放するメンバー関数は便利ですが、必須ではありません。私が言及しているのは、オブジェクトごとのアロケーターのように聞こえ、これは標準に違反していることを知っています。標準に固執したいのですが、その中でこれを解決できない場合は放棄します。

私は初期のパフォーマンスにはあまり関心がなく、平均的なパフォーマンスに関心があります。別の言い方をすれば、一度に単一の要素またはそれらのプールが割り当てられるかどうかは問題ではなく、その割り当てが new/malloc の呼び出しになるかどうかは重要です。私は自分のアロケータを書くことに問題はありませんが、これを達成する既存のアロケータを知っている人はいますか? それが違いを生む場合、これは連続したメモリ コンテナー (vector、deque など) の場合になりますが、一般化されたソリューションが適しています。