検索時間は定数時間です。検索時間は一般に定数時間ですが、配列よりも定数時間だけ長くかかる可能性があります。アイテムはソートされて保管されます。ソートされた順序で列挙されます。ソートされていません。アイテムはソートされずに保管されます。ソートされずに列挙されます。大きな配列へのアイテムの追加・削除は時間がかかる可能性があります。ハッシュテーブルへのアイテムの追加・削除は高速に行われます。配列は中が詰まった構造体であり、アイテムのサイズ以上に消費される領域はありません。ハッシュテーブルは中が詰まった構造体ではありません。実装によりますが、大量のメモリが無駄に消費される可能性があります。実装としては、ハッシュテーブルはキーを渡されるとそのキーに数学的なハッシュ関数を適用してキーを乱数化します。以後、キーのハッシュ値がアイテムの場所の検索に利用されます。優れたハッシュテーブルの実装は、メモリが余計に必要になったとき、または多すぎる量のメモリが割り当てられているとき、自動的にハッシュテーブルのサイズを変更します。どんなときにハッシュテーブルを使うべきですか?ハッシュテーブルは以下のような場合に有用です。高速なランダムアクセスが必要なデータのセット非整数のキー、連続しない整数のキーを持ったデータアイテムの追加・削除が大量に発生するデータ以下のような場合、ハッシュテーブルは利用されるべきではありません。データのセットがソートされている必要がある場合アイテムの数が非常に少ない場合(おおむね12-16個未満)ランダムアクセスを必要としないデータこのような状況では、配列、連結リスト、様々な木構造などが効果的です。いくつかのハッシュテーブルの実装を用意しています。これらはテスト・調整されており、また実装にかかわる内部の複雑さが隠蔽されています。キーとデータを単独の大きな構造体としてメモリ上に格納します。ヒープ領域を効果的に利用します。利用者は「エントリークラス」(訳注:保管するアイテムを表すクラス・構造体)を宣言する必要があります。アイテムへのポインタを別に持っておくことはできません。エントリークラスへのポインタは変化しません。大きな構造体を利用する場合は効果的です。細かなヒープ領域を大量に確保する結果、メモリを無駄に使用することがよくあります。コールバック関数を生成し、ほとんどのキャストを自動的に行います。利用者はキーとデータを保持するエントリークラスを自分で用意します。単純なキー型・データ型を利用する一般的な使い方をする場合は簡単に利用できます。利用者はエントリークラスを宣言・使用する必要がありません。ようなスカラー値を扱います。型はクラスへのポインタ型を扱います。ライブラリからリンクされています。エンジンで広く利用されています。書かれた低レベルな実装です。理解し、利用するためには多少の時間がかかります。ほとんどを読む必要があります。よるラッパ(後述)の方がずっと易しく、また安全です。派生するエントリー構造体を宣言する必要があります。エントリー構造体はハッシュテーブルに格納するデータ(任意のポインタ、固定長のデータ型)を持ちます。実装のため、ハッシュテーブルの内容が変更された際、エントリーはメモリ上で移動される可能性があります。代わりに利用できます。構造体を初期化しなくてはいけません。するための適切なユーザ定義関数へのポインタを提供します。宣言されなければなりません。利用者のコードはこれらのポインタを適切な型にキャストする必要があります。スタック・ヒープのどちらにも配置することができます。破棄される必要があります。テーブルの割り当て・削除を行ってください。