STLの等しくないアロケータについて

Question

C++のアロケータでScott MeyersのEffective STLのItem 10を読んでいます。

標準STLの実装は、同じタイプのすべてのアロケータオブジェクトが等価であると常に が等しい比較こと を想定することが許可されていることを言います。

それはすべてうまくいいですが、あなたはそれについてもっと考えます。 の場合、STL の実装では、同じタイプのアロケータが と同等であると仮定することができます。つまり、 が異なるSTL実装の下で正しく機能する移植可能なアロケータオブジェクト - アロケータ - は に状態を持たない可能性があります。これについて明示しよう：ポータブル アロケータには非静的データメンバーがないことがあり、少なくともその動作に影響するのは ではないことを意味します。なし。ナダ。つまり、 には、1つのヒープから割り当てられる1つのSpecialAllocatorと、異なる ヒープから割り当てられる異なるSpecialAllocatorが割り当てられます（ ）。そのようなアロケータは同等ではなく、両方のアロケータを使用しようとすると ランタイムデータ構造が破損する可能性があるSTL実装 が存在します。標準化委員会に公正で

、私はそれは が同じタイプ のアロケータが等価であると仮定することはSTLの実装を可能にすることで、すぐにテキストの後に次の文を含め ことを指摘すべきである：

実装者が奨励されています... 等しくないインスタンスをサポートするライブラリを提供する。そのような実装では。 ... アロケータインスタンスが非等価オブジェクトである場合のコンテナとアルゴリズム のセマンティクスは、実装定義です。

これは素晴らしい印象ですが、 の状態を持つカスタムアロケータの開発を考慮しているSTLのユーザーとしては、 はあなたの次を提供しません。このステートメント を利用できるのは、（1） を使用しているSTL実装が同等でないアロケータをサポートしていること、（2） の動作が " （3）STL の実装にコードを移植することに心配していません。これは、標準によって緯度が に拡張されていることを明示的に示しています。要するに、この段落 - 段落20.1.5の段落 5。知っていることを主張する人のために、 標準の「1つは夢がある」というアロケータの演説があります。その夢が実現するまで、 は一般的な現実になりますが、移植性について懸念しているプログラマは、 は状態なしのカスタムアロケータに限定されます。

上の段落の私の質問は、著者が非等価または非等しいアロケータで何を

1. 意味していますか？

2. 上記のテキストの最後の段落、つまりポイント3は単純な意味で何を意味しますか？

Answer 1

この情報は最新ではありません。 C++ 11以降のバージョンでは、ステートフルなアロケータがサポートされています。

カスタムアロケータを必要とし、C++ 11を必要とせず、未知の/指定されていない標準ライブラリに対するビルドをサポートするC++ライブラリを作成する場合、Effective C++から投稿した引用符のみが問題になります。最初の近似では、誰もこれをもうやっていません。前にそれをやっていた人は、EASTLやBDESTLのようなステートフルなアロケータをサポートするための独自の "拡張"標準ライブラリ実装をしばしば持っていました。

Answer 2

2つのアロケータは、一方が割り当てたメモリを他方のメモリで解放できる場合は、equalを比較する必要があります。たとえば、保持しているプールから割り当てを行うアロケータオブジェクトは、そのプールからメモリを割り当てて空けることができますが、別のプールを持つ別のアロケータオブジェクトでは（余計な簿記なしで）空きメモリが割り当てられません最初のオブジェクトによって。

アロケータが最初に導入されたときに標準委員会が取りたいと思っていたものを超えていたため、その言葉がすごくうっすらとしていました。そのライセンスは、より新しいバージョンの標準で取り消されました。

最後の段落は、オブジェクトが内部状態に依存するアロケータ（たとえば、上記のプールアロケータ）を書き、使用しているライブラリが等価演算子を尊重している場合（つまり、同じことを比較しないアロケータ間でポインタを渡そうとすると）、等価演算子に注意を払わない別の実装でコードを使用しようとすると、コードが破損します。