問題タブ [allocator]

std::bitset<>インスタンス化時に動的にサイズ変更できる便利なアナログはありますが、boost::dynamic_bitset<>

次のような操作を行うことで、Cで動的なサイズのビットセットを簡単に作成できます。

コンパイル時std::vector<std::bitset<bits>>に知っている場合にのみ、これを使用できます。bitsを使用するstd::vector<boost::dynamic_bitset<>>と、追加のアロケータ呼び出しが表示されます。上記のCコードのバランスを実現する妥協点はありますか？

たとえば、std :: vector <...>用のカスタムアロケータがあり、それぞれの後に余分なスペースを残してそこにboost::dynamic_bitset<>割り当てm_blockますが、それでもおそらくのポインタが必要になりますm_block。

タイプの配列に対してリソース割り当てのクローン作成操作を実装していTます。単純な実装では、ソースから新しい配列への呼び出しがnew T[sz]続きます。std::copy記憶を2回歩きます。

生のメモリを割り当ててから使用したいstd::uninitialized_copyので、パフォーマンス上の理由からメモリを1回だけウォークします。カスタムアロケータが使用されている場合（Allocator.allocateその後にstd::uninitialized_copy）、これを実現する方法を知っています。また、（仕様のセクション20.4.1.1で以下std::allocatorを採用している）を使用してこれを実現する方法を知っています。私の懸念は、定義されているタイプでは、ベースのアプローチが間違っているように見えることです。Boost.TypeTraits'を使用してこのような状況を検出できることはわかっています。::operator newlib.allocator.membersstd::allocatorTT::operator newhas_new_operator

オーバーライドされた新しいメモリを尊重する方法で生のメモリを割り当ててから初期化する（そしてメモリを1回だけ渡す）、単純で標準に準拠した方法はありますか？そうでない場合、SFINAEを使用して、newを使用する実装std::allocatorとオーバーライドされた演算子newを使用する実装の間でディスパッチすることは合理的と思われますか？FWIW、Boostを介してgrepすることは、そのようhas_new_operatorな特性の使用を示していません。

ありがとう、Rhys

別の質問が次の考えに影響を与えました。

容量を増やすときにすべての要素を移動する必要がありますstd::vector<T> か?

私が理解している限り、標準的な動作は、基礎となるアロケーターが新しいサイズのチャンク全体を要求し、次に古い要素をすべて移動し、古い要素を破棄してから古いメモリの割り当てを解除することです。

この動作は、標準のアロケータ インターフェイスを考えると、唯一可能な正しい解決策のようです。しかし、アロケーターを修正して、 a を返し、基になる にマップできるreallocate(std::size_t)関数を提供することは理にかなっているのでしょうか? これの利点は、OS が割り当てられたメモリを実際に拡張できる場合、移動がまったく発生しないことです。ブール値は、メモリが移動したかどうかを示します。pair<pointer, bool>realloc()

(std::realloc()拡張できない場合はデータをコピーする必要がないため、最良の選択ではない可能性があります。したがって、実際には のようなものが必要ですextend_or_malloc_new()。編集:おそらくis_pod-trait ベースの特殊化により、実際のrealloc,そのビット単位のコピーを含みます。一般的にはそうではありません。)

チャンスを逃したようです。最悪の場合、常にreallocate(size_t n)asを実装できるreturn make_pair(allocate(n), true);ため、ペナルティはありません。

この機能を C++ にとって不適切または望ましくないものにする問題はありますか?

おそらく、これを利用できる唯一のコンテナは ですがstd::vector、これも非常に便利なコンテナです。

更新: 明確にするための小さな例。現在resize()：

新しい実装:

次のコードは、バイナリツリーのノードを作成し、それにboost :: shared_ptr（）を返そうとします。

libstdc ++コードを調べると、呼び出しているstd::allocator関数は次のようになっていることがわかりました。

アロケータは、インプレースメントnewを使用して、メモリの割り当てとオブジェクトの構築を分離します。したがって、大量の要素を取得し、オブジェクトが本当に必要な場合にのみコンストラクターを呼び出すことができます。

このcreate_node関数は、アロケータの概念を使用して単一のオブジェクトを作成し、shared_ptrを使用して必要に応じてデストラクタを呼び出します。これらの単一の割り当てを安価にするために、後でアロケータを交換したいと思います（したがって、プール割り当てを使用するアロケータが必要です）。

この関数を呼び出すと、スタック上に一時インスタンスが作成され、ノードの要素がヒープの場所にコピーされます。コンパイラにオブジェクトをすぐに作成させるにはどうすればよいですか？したがって、逆の名前付き戻り値最適化（NRVO）が必要です。これは可能ですか？

allocatorスタック上に存在する（固定サイズの）バッファーを使用するC++標準ライブラリに準拠することが実用的かどうか疑問に思いました。

どういうわけか、この質問はSOでまだこのように尋ねられていないようですが、他の場所で暗黙的に回答されている可能性があります。

したがって、基本的に、私の検索では、固定サイズのバッファーを使用するアロケーターを作成できるはずです。さて、一見すると、これは、スタック上に「存在する」固定サイズのバッファを使用するアロケータを持つことも可能であることを意味するはずですが、そのような実装は広く普及していないようです。

私が意味することの例を挙げましょう：

これはどのように実装できますか？

この他の質問への回答（R. Martinho Fernandesに感謝）は、クロムソースからのスタックベースのアロケータにリンクしています：http ：//src.chromium.org/viewvc/chrome/trunk/src/base/stack_container.h

ただし、このクラスは非常に独特なようです。特にStackAllocator 、デフォルトのctorがないためです。そこで、すべてのアロケータクラスにデフォルトのctorが必要だと考えていました。

簡単な C++11 スタイルのステートフル アロケーター型を作成しました。与えられた

デフォルトのアロケータを使用しmy_vectorて a から a への変換を許可する最良の方法は何ですか? std::vectorGCC 4.7（最近のsvn）は言う

error: conversion from 'my_vector<int> {aka std::vector<int, my_allocator<int>>}' to non-scalar type 'std::vector<int>' requested

明らかに、これは次のような単純な変換関数で行うことができます。

しかし、これはかなり洗練されていないようです。C++11 でより良い解決策はありますか?

もちろん、この状況では移動セマンティクスは適切ですが、余分なノイズやタイピングなしでコピーの構築と代入が機能することを望みます。

SSEを使用してデータを処理する場合は、std::vector16バイトのアライメントが必要です。どうすればそれを達成できますか？自分でアロケータを書く必要がありますか？または、デフォルトのアロケータはすでに16バイト境界に整列していますか？

以下のコード リストのように、任意のアロケーターを使用して割り当てられたプリミティブ型の配列に対して allocator.construct() を呼び出す必要がありますか? クラスは、割り当てられたメモリを特定の値に初期化する必要がないため、新しく割り当てられたメモリのチャンクで allocator.construct() を呼び出す必要はないように思えます。配列が常にプリミティブ型で構成されている場合、このメソッドを呼び出さないことに危険はありますか?

基本的な文字列の実装のいくつかと少し混乱しています。私は内部の働きを理解し、新しいことを学ぶためにソースを調べてきました. メモリがどのように管理されているか完全には把握できません。

基本的な文字列の実装からのちょっとしたヒント

• 生のアロケータは char 型用です

  /li>

• ...次に、割り当て時に Rep が割り当てられたバッファ内に配置され__size、文字に適合するように計算されます

  /li>

• これは、文字データが _Rep バッファーからフェッチされる方法です。

  /li>

• キャラクターの設定 - 1 種類の方法

  /li>

私を悩ませているのは、生のアロケーターが char 型ですが、割り当てられたメモリが _Rep オブジェクトと文字データ (char 型である必要はありません) を保持している可能性があることです。

また、なぜ（またはどのように）_M_refdata文字データの開始（または終了）がバッファ内のどこにあるかを知るための呼び出しを行います（つまりthis+1）

編集:内部ポインタをオブジェクトthis+1の次の位置にプッシュするだけですか?_Rep

私はメモリの配置とキャストの基本的な理解を持っていますが、これは私が読んだものを超えているようです.

誰か助けてくれますか、またはより有益な読み物を教えてくれますか?