「新しいプレースメント」にはどのような用途がありますか？

C ++の「プレースメント新品」を使った人はいますか？もしそうなら、何のために？メモリマップされたハードウェアでのみ役立つように思えます。

新しい配置により、すでに割り当てられているオブジェクトをメモリ内に構築できます。

オブジェクトの複数のインスタンスを作成する必要があり、新しいインスタンスが必要になるたびにメモリを再割り当てしない方が速い場合は、最適化のためにこれを行うことができます。代わりに、一度にすべてを使用したくない場合でも、複数のオブジェクトを保持できるメモリのチャンクに対して単一の割り当てを実行する方が効率的です。

DevXは良い例です：

標準C ++は、事前に割り当てられたバッファにオブジェクトを構築する配置新しい演算子もサポートします。これは、メモリプール、ガベージコレクターを構築する場合、または単にパフォーマンスと例外の安全性が最重要である場合に便利です（メモリが既に割り当てられているため、割り当てに失敗する危険はなく、事前に割り当てられたバッファーにオブジェクトを構築するのにかかる時間は短くなります）。 ：

char *buf  = new char[sizeof(string)]; // pre-allocated buffer
string *p = new (buf) string("hi");    // placement new
string *q = new string("hi");          // ordinary heap allocation

重要なコードの特定の部分（ペースメーカーによって実行されるコードなど）で割り当てエラーが発生しないようにすることもできます。その場合は、先にメモリを割り当ててから、クリティカルセクション内の配置newを使用します。

新しい配置での割り当て解除

メモリバッファを使用しているすべてのオブジェクトの割り当てを解除しないでください。代わりに、元のバッファのみを削除する必要があります。その後、クラスのデストラクタを手動で呼び出す必要があります。これに関する良い提案については、StroustrupのFAQを参照してください：「プレースメントの削除」はありますか？

カスタムメモリプールで使用します。単なるスケッチ：

class Pool {
public:
    Pool() { /* implementation details irrelevant */ };
    virtual ~Pool() { /* ditto */ };

    virtual void *allocate(size_t);
    virtual void deallocate(void *);

    static Pool::misc_pool() { return misc_pool_p; /* global MiscPool for general use */ }
};

class ClusterPool : public Pool { /* ... */ };
class FastPool : public Pool { /* ... */ };
class MapPool : public Pool { /* ... */ };
class MiscPool : public Pool { /* ... */ };

// elsewhere...

void *pnew_new(size_t size)
{
   return Pool::misc_pool()->allocate(size);
}

void *pnew_new(size_t size, Pool *pool_p)
{
   if (!pool_p) {
      return Pool::misc_pool()->allocate(size);
   }
   else {
      return pool_p->allocate(size);
   }
}

void pnew_delete(void *p)
{
   Pool *hp = Pool::find_pool(p);
   // note: if p == 0, then Pool::find_pool(p) will return 0.
   if (hp) {
      hp->deallocate(p);
   }
}

// elsewhere...

class Obj {
public:
   // misc ctors, dtors, etc.

   // just a sampling of new/del operators
   void *operator new(size_t s)             { return pnew_new(s); }
   void *operator new(size_t s, Pool *hp)   { return pnew_new(s, hp); }
   void operator delete(void *dp)           { pnew_delete(dp); }
   void operator delete(void *dp, Pool*)    { pnew_delete(dp); }

   void *operator new[](size_t s)           { return pnew_new(s); }
   void *operator new[](size_t s, Pool* hp) { return pnew_new(s, hp); }
   void operator delete[](void *dp)         { pnew_delete(dp); }
   void operator delete[](void *dp, Pool*)  { pnew_delete(dp); }
};

// elsewhere...

ClusterPool *cp = new ClusterPool(arg1, arg2, ...);

Obj *new_obj = new (cp) Obj(arg_a, arg_b, ...);

これで、オブジェクトを単一のメモリアリーナにクラスタリングし、非常に高速であるが割り当て解除を行わないアロケータを選択し、メモリマッピングを使用し、プールを選択してオブジェクトの配置への引数としてそれを課すことによって課したいその他のセマンティクスを使用できます。新しいオペレーター。

割り当てと初期化を分離したい場合に便利です。STLは新しい配置を使用してコンテナー要素を作成します。

リアルタイムプログラミングで使用しました。通常、システムの起動後に動的割り当て（または割り当て解除）を実行する必要はありません。これには、かかる時間が保証されていないためです。

私ができることは、メモリの大きなチャンクを事前に割り当てることです（クラスが必要とするものをいくらでも保持するのに十分な大きさ）。次に、実行時に物事を構築する方法を見つけたら、新しい配置を使用して、必要な場所にオブジェクトを構築できます。私がそれを使用したことがわかっている1つの状況は、異種混合循環バッファーの作成を支援することでした。

それは確かに心臓の弱い人のためではありませんが、それが彼らがそのための構文をちょっと危険にしてしまう理由です。

alloca（）を使用してスタックに割り当てられたオブジェクトを構築するために使用しました。

恥知らずなプラグイン：私はそれについてここでブログに書いた。

ヘッドオタク：ビンゴ！あなたはそれを完全に手に入れました-それはまさにそれが完璧なものです。多くの組み込み環境では、外部制約や全体的な使用シナリオにより、プログラマーはオブジェクトの割り当てを初期化から切り離す必要があります。まとめると、C ++はこれを「インスタンス化」と呼びます。ただし、動的または自動割り当てなしでコンストラクターのアクションを明示的に呼び出す必要がある場合は常に、新しい配置がその方法です。また、ハードウェアコンポーネント（メモリマップI / O）のアドレスに固定されているグローバルC ++オブジェクト、または何らかの理由で固定アドレスに存在する必要がある静的オブジェクトを見つけるのに最適な方法でもあります。

私はそれをVariantクラス（つまり、いくつかの異なるタイプの1つになることができる単一の値を表すことができるオブジェクト）を作成するために使用しました。

Variantクラスでサポートされているすべての値型がPOD型（int、float、double、boolなど）の場合、タグ付きのCスタイルの共用体で十分ですが、一部の値型をC ++オブジェクトにする場合（例えばstd :: string）の場合、非PODデータ型は共用体の一部として宣言されない可能性があるため、Cの共用体機能は機能しません。

したがって、代わりに、十分な大きさのバイト配列（sizeof（the_largest_data_type_I_support）など）を割り当て、Variantがその型の値を保持するように設定されている場合は、配置newを使用してその領域の適切なC ++オブジェクトを初期化します。（もちろん、別の非PODデータ型から切り替える場合、配置は事前に削除されます）

新しい配置は、シリアライズするときにも非常に便利です（たとえば、boost :: serializationで）10年間のc ++では、これは私が新しい配置を必要とした2番目のケースにすぎません（インタビューを含めると3番目）:)）。

また、グローバルまたは静的に割り当てられた構造を再初期化する場合にも役立ちます。

古いCの方法では、memset()すべての要素を0に設定するために使用していました。C++では、vtablesとカスタムオブジェクトコンストラクターのため、これを行うことはできません。

だから私は時々以下を使います

 static Mystruct m;

 for(...)  {
     // re-initialize the structure. Note the use of placement new
     // and the extra parenthesis after Mystruct to force initialization.
     new (&m) Mystruct();

     // do-some work that modifies m's content.
 }

これはどの回答でも強調されていないと思いますが、新しい配置の別の良い例と使用法は、（メモリプールを使用して）メモリの断片化を減らすことです。これは、組み込みシステムおよび高可用性システムで特に役立ちます。この最後のケースでは、24/365日稼働する必要のあるシステムでは断片化がないことが非常に重要であるため、これは特に重要です。この問題は、メモリリークとは関係ありません。

非常に優れたmalloc実装（または同様のメモリ管理機能）が使用されている場合でも、断片化を長期間処理することは非常に困難です。ある時点で、メモリの予約/解放の呼び出しを巧みに管理しないと、再利用（新しい予約への割り当て）が困難な小さなギャップが多数発生する可能性があります。したがって、この場合に使用されるソリューションの1つは、メモリプールを使用して、アプリケーションオブジェクトのメモリを事前に割り当てることです。その後、オブジェクトのメモリが必要になるたびに、新しい配置を使用して、すでに予約されているメモリ上に新しいオブジェクトを作成します。

このように、アプリケーションが起動すると、必要なすべてのメモリがすでに予約されています。すべての新しいメモリの予約/解放は、割り当てられたプールに行きます（オブジェクトクラスごとに1つずつ、複数のプールがある場合があります）。この場合、メモリの断片化は発生しません。ギャップが発生せず、システムは断片化の影響を受けることなく非常に長い期間（数年）実行できるためです。

VxWorks RTOSの場合、デフォルトのメモリ割り当てシステムは断片化の影響を大きく受けるため、これを実際に見ました。したがって、プロジェクトでは、標準のnew / mallocメソッドを使用してメモリを割り当てることは基本的に禁止されていました。すべてのメモリ予約は、専用のメモリプールに移動する必要があります。

実際には、挿入される要素の数に最小限必要なメモリよりも多くのメモリを割り当てるあらゆる種類のデータ構造（つまり、一度に1つのノードを割り当てるリンク構造以外のもの）を実装する必要があります。

以下のようなコンテナを取るunordered_map、vectorまたはdeque。これらはすべて、1回の挿入ごとにヒープ割り当てを必要としないようにするために、これまでに挿入した要素に最低限必要なメモリよりも多くのメモリを割り当てます。vector最も単純な例として使用してみましょう。

あなたがするとき：

vector<Foo> vec;

// Allocate memory for a thousand Foos:
vec.reserve(1000);

...実際に1000のFoosを構築するわけではありません。単にメモリを割り当てる/予約するだけです。vectorここで新しい配置を使用しなかった場合、それはFoos場所全体にデフォルトで構築され、最初の場所に挿入したことのない要素に対してもデストラクタを呼び出す必要があります。

割り当て！=構築、解放！=破壊

上記のような多くのデータ構造を実装するために一般的に言えば、メモリの割り当てと要素の構築を1つの不可分なものとして扱うことはできません。同様に、メモリの解放と要素の破壊を1つの不可分なものとして扱うこともできません。

コンストラクタとデストラクタを不必要に左右に呼び出さないようにするには、これらのアイデアを分離する必要があります。そのため、標準ライブラリはstd::allocator（メモリの割り当て/解放時に要素を構築または破棄しない*）というアイデアをそれを使用するコンテナは、配置newを使用して要素を手動で構築し、デストラクタの明示的な呼び出しを使用して要素を手動で破棄します。

• 私はデザインが嫌いですstd::allocatorが、それは私が怒って避けるのは別の主題です。:-D

とにかく、既存のものでは構築できない汎用の標準準拠のC ++コンテナーを多数作成したので、とにかく私はそれを頻繁に使用する傾向があります。その中に含まれているのは、一般的なケースでのヒープ割り当てを回避するために数十年前に作成した小さなベクトル実装と、メモリ効率の良いトライ（一度に1つのノードを割り当てない）です。どちらの場合も、既存のコンテナーを使用してそれらを実際に実装することはできなかったため、placement new左と右の不要なものに対してコンストラクターとデストラクターを過剰に呼び出すことを避けるために使用する必要がありました。

もちろん、カスタムリストを使用してオブジェクトを個別に割り当てる場合（フリーリストなど）、通常placement newは次のようにを使用することもできます（例外安全性やRAIIを気にしない基本的な例）：

Foo* foo = new(free_list.allocate()) Foo(...);
...
foo->~Foo();
free_list.free(foo);

カーネルを構築している場合に便利です。ディスクまたはページテーブルから読み取ったカーネルコードはどこに配置しますか？ジャンプ先を知る必要があります。

または、割り当てられた部屋がたくさんあり、いくつかの構造物を互いに後ろに配置したい場合など、非常にまれな状況です。これらは、offsetof（）演算子を必要とせずに、この方法でパックできます。ただし、他にもトリックがあります。

また、STD :: vectorのように、いくつかのSTL実装が新しい配置を利用していると思います。それらは2 ^ n要素のスペースをそのように割り当て、常に再割り当てする必要はありません。

それはで使用されていますstd::vector<>のでstd::vector<>、通常よりも多くのメモリ割り当てobjectsにしますvector<>。

私は、メモリマップファイルを含むオブジェクトを格納するために使用しました。
具体的な例は、大量の大きな画像（メモリに収まりきらない）を処理する画像データベースでした。

私はそれが「動的タイプ」ポインタ（セクション「フードの下」）のわずかなパフォーマンスハックとして使用されるのを見てきました。

しかし、ここで私が小さなタイプの高速パフォーマンスを取得するために使用したトリッキーなトリックがあります：保持されている値がvoid *の内側に収まる場合、実際には新しいオブジェクトの割り当てを気にせず、配置newを使用してそれをポインター自体に強制します。

ネットワークから受信したメッセージを含むメモリに基づいてオブジェクトを作成するために使用しました。

一般に、新しい配置は、「通常の新規」の割り当てコストを取り除くために使用されます。

私がそれを使用した別のシナリオは、ドキュメントごとのシングルトンを実装するために、まだ作成されていないオブジェクトへのポインターにアクセスしたい場所です。

共有メモリを使用する場合などに便利です。例：http : //www.boost.org/doc/libs/1_51_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.conditions。 conditions_anonymous_example

私がそれに遭遇した1つの場所は、連続したバッファーを割り当て、必要に応じてオブジェクトでそれを埋めるコンテナーです。前述のように、std :: vectorがこれを実行する可能性があり、MFC CArrayやCListの一部のバージョンがこれを実行したことを知っています（これが私が最初に遭遇した場所だからです）。バッファーの過剰割り当て方法は非常に便利な最適化であり、新規配置は、そのシナリオでオブジェクトを構築するためのほとんど唯一の方法です。また、直接コードの外部に割り当てられたメモリブロック内のオブジェクトを構築するために使用されることもあります。

あまり出てこないのですが、同じくらいの容量で使いました。ただし、C ++ツールボックスには便利なツールです。

スクリプトエンジンは、それをネイティブインターフェイスで使用して、スクリプトからネイティブオブジェクトを割り当てることができます。例については、Angelscript（www.angelcode.com/angelscript）を参照してください。

http://xll.codeplex.comにあるxllプロジェクトのfp.hファイルを参照してください。これにより、次元を持ち運びたい配列の「コンパイラによる不当な混乱」の問題が解決されます。

typedef struct _FP
{
    unsigned short int rows;
    unsigned short int columns;
    double array[1];        /* Actually, array[rows][columns] */
} FP;

C ++のインプレースコンストラクターのキラーな使用法は次のとおりです。キャッシュラインと2つの境界のその他の累乗に合わせます。これが、5以下のシングルサイクル命令で2のべき乗の境界に対応する超高速ポインタアライメントアルゴリズムです。

/* Quickly aligns the given pointer to a power of two boundary IN BYTES.
@return An aligned pointer of typename T.
@brief Algorithm is a 2's compliment trick that works by masking off
the desired number in 2's compliment and adding them to the
pointer.
@param pointer The pointer to align.
@param boundary_byte_count The boundary byte count that must be an even
power of 2.
@warning Function does not check if the boundary is a power of 2! */
template <typename T = char>
inline T* AlignUp(void* pointer, uintptr_t boundary_byte_count) {
  uintptr_t value = reinterpret_cast<uintptr_t>(pointer);
  value += (((~value) + 1) & (boundary_byte_count - 1));
  return reinterpret_cast<T*>(value);
}

struct Foo { Foo () {} };
char buffer[sizeof (Foo) + 64];
Foo* foo = new (AlignUp<Foo> (buffer, 64)) Foo ();

今、それはあなたの顔を笑顔にするだけではありません（:-)。私♥♥♥C ++ 1x