std.experimental.allocator.building_blocks.affix_allocator

struct AffixAllocator(Allocator, Prefix, Suffix = void);

割り当ての前(Prefix 型)および／または後( 型)に余分なデータを追加するアロケータ。 (型はSuffix)の前後に追加するソースアロケータである。これは これは、追加のアロケーション関連情報が必要な場合に便利である。 これは、ミューテックス、参照カウント、メモリ破壊エラーのデバッグ用のウォールなど、追加のアロケーション関連情報が必要な場合に便利である。

Prefix がvoid でない場合、Allocator は少なくとも と同じ大きさのアライメントを保証しなければならない。 Prefix.alignofと同程度のアライメントを保証しなければならない。

接尾辞はアライメントの丸め込みのため、取得に時間がかかる。 が望ましい。しかし、小さな接頭辞はアライメントを鈍らせる。 小さな接頭辞で大きなアライメントが必要な場合は、接尾辞を選ぶべきである。

以下のメソッドは、Allocator で定義されている場合に定義される:deallocateAll empty,owns.

Examples:

import std.experimental.allocator.mallocator : Mallocator;
// One word before and after each allocation.
alias A = AffixAllocator!(Mallocator, size_t, size_t);
auto b = A.instance.allocate(11);
A.instance.prefix(b) = 0xCAFE_BABE;
A.instance.suffix(b) = 0xDEAD_BEEF;
assert(A.instance.prefix(b) == 0xCAFE_BABE
    && A.instance.suffix(b) == 0xDEAD_BEEF);

enum uint alignment;

Prefix がvoid の場合、アライメントは親のアライメントとなる。そうでない場合、アライメントはPrefix のアライメントと同じである。

Allocator _parent;

親アロケータAllocator がステートフルな場合、そのインスタンスがメンバとして格納される。 メンバとして格納される。そうでない場合、AffixAllocator は Allocator.instance.いずれの場合も、名前 _parentという名前が使われる。 を使う。

pure nothrow @nogc @safe Allocator parent();

親アロケータAllocator がステートフルな場合、そのインスタンスがメンバとして格納される。 メンバとして格納される。そうでない場合、AffixAllocator 。 Allocator.instance.どちらの場合でも、_parent という名前が一律に使われる。 という名前で統一される。

size_t goodAllocSize(size_t);

void[] allocate(size_t);

Ternary owns(void[]);

bool expand(ref void[] b, size_t delta);

bool reallocate(ref void[] b, size_t s);

bool deallocate(void[] b);

bool deallocateAll();

Ternary empty();

標準のアロケータ・メソッド。それぞれが定義されているのは、親 アロケータが同音異義語のメソッドを定義している場合にのみ定義される。 goodAllocSize, は除く)。また、親アロケータがメソッドを定義している場合は、 shared 。

static AffixAllocator instance;

また instanceシングルトンが定義されるのは、親アロケータが がステートを持たず、独自のit オブジェクトを定義している場合に限り定義される。

ref auto prefix(T)(T[] b);

ref auto suffix(T)(T[] b);

への参照を提供するアフィックスアクセス関数である。 ブロック bへの参照を提供するアフィックスアクセス関数である。 bはNULLであってはならない。 対応する接辞がvoid でない場合にのみ定義される。

接辞の修飾子は必ずしも引数の修飾子と同じとは限らない。 と同じとは限らない。これは、接辞がデータの一部ではなく、データ自体と関連付けられているだけだからである。 の一部ではなく、データに関連付けられ、アロケータが知っているだけだからである。 アロケータが知っているからである。以下の表は、アロケータのアフィックスの型を示している。 preffix(b)と affix(b)の型によって異なる。 b.

結果 prefix/suffix引数による (U は 任意の非限定型、Affix はPrefix またはSuffix)

引数の型	戻り値	コメント
shared(U)[]	ref shared Affix	データはスレッド間で共有され、アロケータもそれに従う。
immutable(U)[]	ref shared Affix	データは不変のものであるが、アロケータはその下のメモリが変更可能であることを「知っている」。 そのため、immutable は省略される。 を省略した。しかし、結果は shared というのも、immutable は暗黙のうちに共有可能だからである。 スレッドが同じデータの接辞にアクセスし、操作することができる。
const(shared(U))[]	ref shared Affix	データは常にスレッド間で共有可能である。たとえデータが がconst の場合と同じ理由で、接辞は変更可能である。 immutable.
const(U)[]	ref const Affix	入力はU[] 、またはimmutable(U)[] 、 であるため、実際に共有されているかどうかはわからない。修飾されていない接辞 shared を返すと、競合状態が発生する可能性がある。 を返すと、複数のスレッド間で変更可能なスレッドローカルデータを不注意に共有することになる。 を不注意に共有してしまう可能性がある。そのため、返される型は保守的に ref const.
U[]	ref Affix	非修飾データは非修飾接辞を持つ。

前提条件 b !is nullそして bは で確保されていなければならない。