既然 ACM 選手發明了那麼多數據結構，那麼能不能寫一個「二階」程序，根據需求返回性能最好的一個來？

01-08

.Net裡面有一個HybridDictionary，會根據負載切換使用HashTable還是別的什麼東西來實現，算是這種模式的一個實例吧

這莫非就是失傳多年的AC自動機么！

只要你能把這些不同的數據結構靜態地delegate到一個相同的介面，你就可以先隨便選一個AC，然後系統幫你把所有的數據結構的組合試一遍，得到最好的那個

根據需求不同，總會需要對代碼進行微調的。如果要做到足夠的靈活、足夠通用，那種「工業強度」的代碼大概不是ACMer們追求的吧，而且這樣會帶來性能損失。

最符合題主需求的這個二階函數大概就是一個優秀的ACMer本人了。畢竟把不同的需求「量化」進行比較，還是人腦比較適合做。

第一，大部分數據結構不是ACMer發明的。

第二，大部分ACMer本身就是一個人肉的「二階」程序，他們的任務就是根據題目描述，選擇一個性能最好的，不僅僅是這樣，因為追求更好的性能並不一定是最好的，一個性能剛好夠而且生產時間最短演算法才是最優的。所以評判標準在AC與否的基礎上還加了時間排名，這很科學。

第三，為什麼不做一個這樣的程序呢？嗯，我們來寫一個能為任何問題給出一個最優數據結構的程序吧，那我們怎麼寫呢，第一部先讓這個程序來確定最優的數據結構啊（對於大部分問題，確定最優數據結構的演算法就幾乎確定了最優演算法）

（這裡的最優指的是在滿足問題約束的情況下工程量最小，換而言之就是如果我們的二階程序的時間複雜度不是常數，那麼在滿足輸入約束的前提下使得二階程序的運行時間最短）

（如果你招的碼農自願加班並且不要加班費還在家裡加班不用公司電費不會猝死和辭職，那麼這個可以近似的認為你的二階程序運行時間為常數。）

一些（分治，搜索）演算法自帶「當範圍小到多少的時候直接暴力/dp/貪心......」的做法。不知道滿不滿足題主的要求。

在程序實現上來說絕對是允許的，只不過絕大部分題目只使用使用一種主要的數據結構，或者兩種主要數據結構的混合就可以解決。實際工程當中這樣做除了增加些代碼量之外好像就沒什麼副作用了。

先要有人有動力把這些東西寫出足夠魯棒標準的介面，並且把各種細節寫到足夠好吧……

———————————————————————————————————————

然後我們來寫一個上層的「二階」程序，鑒於我們拿不到細緻的數據分布，我們在任何情況下都返回紅黑樹好啦，可喜可賀，可喜可賀。

參見各種語言的實際排序演算法

另外， Generality, Simplicity, Quality 三者很難兼得呀。

然而acm比賽時只讓帶紙質材料，所以acmer是不會願意去搞這種事的

std::sort

比賽的時候一般都是在時限內選擇最好寫的那個