ハッシュテーブルの挿入/ルックアップ/削除インターフェイスを提供する必要があります。内部バケット/エントリ管理を提供するためだけにハッシュテーブルを作成しました。ハッシュ関数は外部から提供する必要があります。ハッシュテーブルが固定長のデータ型だけでなくバイト配列も処理できるように、インターフェイスを公開する方法に固執しています。問題は、バイト配列の場合、ハッシュ関数は配列の長さを知る必要があるのに対し、他のタイプの場合は、その情報がなくても実行できることです。私の問題はoperator[]
、ハッシュ関数が2つのパラメーターを必要とするため、バイト配列を実装できないことです。operator[]
そして、私は心から保ちたいと思います。これを回避する方法はありますか(特殊化せず、その特殊化でT*
コンパイラエラーをスローしoperator[]
ません)?
2 に答える
ハッシュテーブルのoperator[]が、格納しているデータ型のoperator []と競合する場所がわからないため、ここで混乱しています。
hash_tableにoperator[]がある場合、これは、operator []にキーを指定するhash_mapであるか、operator[]がセルの内容を返す可能性があります。
通常、独自のハッシュテーブルを実装する場合、データをエントリに直接保存するのではなく、データといくつかの「メタデータ」、つまりセルに関連する情報を保存します。ハッシュテーブルは削除をサポートしているため、そのようなセルを見つけるための現在の戦略が何であれ、おそらく他の場所に移動された衝突に到達できることを確認する必要があります。したがって、削除されたセルは使用可能ですが、衝突コースのパスの一部である可能性があるため、占有されたことのないセルとは異なる意味を持ちます。
あなたが言うように、ハッシュ関数は独立しています。したがって、ストレージメカニズムから独立しており、ハッシュテーブルのoperator[]をまったく呼び出しません。
ハッシュテーブルは、ハッシュ関数と比較関数のみを使用し、それ以外の場合は、独自のストレージポリシーと衝突処理ポリシーを使用します。
バイト配列と固定長データ型を処理できます
したがって、バイト配列のサイズは異なります。それぞれの長さをどこかに記録する必要があります。それらを値ごとにハッシュテーブルに格納する場合は、データと長さの値をオブジェクトにパッケージ化できます。STLには、std ::vector<>やstd::string<などのこれに適したクラスがすでに用意されています。 >。または、ハッシュテーブルにバイト配列へのポインタ/参照のみを格納する場合は、長さを格納または確認し、データへのポインタ/参照を持つ簡単な「ハンドル」クラスを作成できます。
「CashCow」が指摘しているようoperator[]
に、バイト配列とハッシュテーブルの間に固有の競合はありません...必要に応じてチェーンすることもできます。