欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

當初制定CPP98時(shí)，時(shí)間緊迫，要想知道為什么選用RB-Tree而不是hash的原因必須先了解RB-Tree和hash的差別：
a. RB-Tree的查找和刪除時(shí)間復雜度是log(o)，而hash呢，快的時(shí)候是常數級，慢的時(shí)候（碰撞）也關(guān)系不大。
b. 插入：RB-Tree仍然是log(o)，而hash快的時(shí)候同樣是常數級，但最慢的時(shí)候可能需要重新分配內存和重新構造hash。
結論是：
RB-Tree效率穩定，而hash在基于隨即統計上比RB-Tree要快。
所以：
a. 首先從需求上考慮到底使用哪個(gè)容器，比如某個(gè)用戶(hù)查詢(xún)，用RB-Tree一萬(wàn)次，每次需要花費2秒；用hash，9999次每次花費1秒，但有一次需要花費10000秒。此時(shí)，你應該選用哪個(gè)？雖然總體時(shí)間上還是hash快，但哪個(gè)花費了10000秒的用戶(hù)可不同意這種說(shuō)法。
b. 對于既可以使用RB-TREE又可以使用hash的情況下，要根據數據量，已經(jīng)這些數據的統計學(xué)特性來(lái)選擇相應的容器。

RB-Tree未必總是效率穩定的。比如查找長(cháng)度1000的string key和查找長(cháng)度為1的string key的時(shí)候，RB tree顯然將由于string.compare的工作量差異而出現總體上的效率差異；而此時(shí)hash表反而可以表現出穩定的效率。
再者，tree中存放的具體內容，會(huì )影響每次string.compare的工作量，從而影響RB-Tree的總體效率。而hash表受具體內容的影響就比較小，因為hash表的compare次數比較少。

以上都是理論分析。在對程序效率有要求的實(shí)際應用中，我還沒(méi)遇到紅黑樹(shù)比哈希表更優(yōu)秀的情況。
能不能請樓上舉一個(gè)具體的例子呢？

PS：我承認我在邏輯上處于不利地位，因為我是要證明“命題總是成立”，而樓上只需要舉一個(gè)例子反證就可以了。不過(guò)我仍然對此躍躍欲試。