2013-02-22 21 views
1

在用C編寫的散列表的單獨鏈接實現中,我允許以LIFO順序插入和刪除重複鍵。調整具有可能重複鍵的單獨鏈接散列表的大小

調整表格大小的條件(是其大小的兩倍)是當每個列表平均包含10個項目時。該代碼看起來是這樣的:

void maybeExpand(Hashtable* table) 
{ 
    if (table->items < table->lists * 10) 
     return; 

    /* resize */ 
} 

請注意,我的項目數之間的比例比較到號碼列表,而不是哈希表的全部容量的。

問題是當表只包含重複鍵,每個列表的平均項數大於10時。調整大小不會改變列表數和項數,所以哈希表只會不斷調整大小。

我不知道是否允許在一個哈希表中重複鍵是一個很好的決定,如果是的話,在上述情況下該怎麼辦?

+0

基於列表數量而不是整個表格大小調整大小的理由是什麼? – 2013-02-22 15:39:14

+0

表的整個大小可能比列表的數量大得多。如果我依賴整個表的大小,那麼長列表可以存在,但在插入多個項目之前不會調整大小。 – 2013-02-22 15:50:05

+0

您應該考慮_keys_的數量,而不是數據項的數量。我會讓每個鍵有一個項目隊列,而不是重複的鍵與奇怪地處理數據。清潔劑,IMVHO。 – vonbrand 2013-02-22 23:38:41

回答

0

無論你需要一個散列表,它允許每個鍵上有多個值,或者一個簡單覆蓋的值取決於的情況,如果對如何使用散列表有疑問,可以使用某種開關來提供。

所有條目被哈希到相同的情況hashbucket很難預測。選擇一個好的散列函數在任何情況下都是很好的投資;但總的來說,你只應該針對平均情況進行優化,而不是最壞的情況。

+0

但是這種情況並不是典型的最壞情況,取決於散列函數。無論如何,散列函數必須爲相同的密鑰提供相同的散列值。 – 2013-02-22 15:38:41

+0

完全相同的鍵。 – 2013-02-22 15:39:22

+0

但這不是優化相關的。使用該邏輯可能會導致崩潰,因爲重新哈希不會改變任何內容(重新哈希相同的密鑰最終會在同一個桶中),並且哈希表將不斷擴展。 – 2013-02-22 16:15:54

相關問題