@唐風(fēng)
重復(fù)數(shù)量有限而且不多時(shí)，還是可以接受的……
范型庫經(jīng)常會(huì)做這種事情。比如iterator_traits，numeric_limits……

concepts嘛…… 砍了也好……
支持C++標(biāo)準(zhǔn)的謹(jǐn)慎態(tài)度。

沒有concepts，雖然代碼很難寫，但也已經(jīng)寫出來了。
但concepts一旦加入標(biāo)準(zhǔn)，又發(fā)現(xiàn)它不是想象中那么好的話，就再也拿不掉了。

C++就是拿boost這種庫當(dāng)試驗(yàn)田。
等某個(gè)特性確實(shí)各方面都符合條件時(shí)，再加入標(biāo)準(zhǔn)之中。
而不像java、.net，動(dòng)不動(dòng)就加入一個(gè)；過段時(shí)間發(fā)現(xiàn)不好，再加入一個(gè)替代品；使得庫很臃腫；還要一直保持向下兼容。
C++不是商業(yè)公司擁有的…… 沒人有這么好的精力做這些事情……

@溪流
哈哈，被你看出來了……
我就是一anti-OOP者……

其實(shí)也不是完全是這樣。只是太多人將OOP當(dāng)作萬能藥了。
以為OOP的設(shè)計(jì)，就一定是好的設(shè)計(jì)。OOP成分越多，設(shè)計(jì)越好。
我反對(duì)的是這種態(tài)度。

@溪流
我再使用上面的觀點(diǎn)狡辯一次吧……

1. 非虛析構(gòu)
如果、假設(shè)、萬一真的出現(xiàn)了這樣的需求 —— 幾乎不可能 —— 需要被繼承而且以父類指針delete子類。

還可以這樣：
class StringDerivable {
String s_;
public:
virtual ~StringDerivable();
};
并從StringDerivable繼承。


2. 虛析構(gòu)
如果一開始就使用虛析構(gòu)，無論是否需要被繼承 —— 幾乎不可能 —— 用戶都必須承擔(dān)一個(gè)虛指針的代價(jià)。


非虛析構(gòu)對(duì)于不需要繼承的客戶來說，沒有額外的代價(jià)。對(duì)需要繼承的變態(tài)客戶來說，也有辦法實(shí)現(xiàn) —— 多一個(gè)步驟。
這是貫穿整個(gè)C++語言設(shè)計(jì)的一個(gè)重要原則：0代價(jià)原則。
虛析構(gòu)無論客戶是否需要，多態(tài)的代價(jià)都必須承受。


設(shè)計(jì)不單單只是你做了什么，也包括你沒有做什么。

代碼字體挺好看的。
知名應(yīng)用抄錯(cuò)了：

enum {value = sizeof(test<T>()) == sizeof(one)};

這里要以一個(gè)0去調(diào)用test<T>：
enum {value = sizeof(test<T>(0)) == sizeof(one)};
如果T不是內(nèi)建類型，0就可以隱式轉(zhuǎn)換到T的成員的指針，否則匹配省略號(hào)版本。


詳細(xì)見這里，包含一個(gè)更簡單的不使用SFINAE實(shí)現(xiàn)(代碼也更多)is_buildin的方法：
http://m.shnenglu.com/Charlib/archive/2009/03/16/76799.html

@李佳
如果只是練習(xí)著玩玩，機(jī)器碼寫都沒問題。

如果是實(shí)際應(yīng)用上，這么實(shí)現(xiàn)這么簡單的需求 —— 10行代碼了事 ——用到匯編和線程局部存儲(chǔ)，那……
有點(diǎn)過了……

別搞了兄弟，用vsprintf之類的函數(shù)就可以了。

@溪流
何時(shí)需要虛析構(gòu)函數(shù)？當(dāng)通過父類類指針delete子類時(shí)。
String這種類型不應(yīng)該作為基類，也不應(yīng)該被多態(tài)使用，所以虛析構(gòu)函數(shù)是不必要的。

@溪流
一個(gè)虛函數(shù)都沒有，繼承來做啥？

SetProp/GetProp …… 居然還有這種函數(shù)……

SetWindowLongPtr(hwnd, i , data );
data = GetWindowLongPtr(hwnd, i );

i 是一個(gè)數(shù)組的index。
數(shù)組大小和窗口注冊(cè)時(shí)填入的cbWndExtra有關(guān)。

有個(gè)重要的地方忘記說了……
虛析構(gòu)函數(shù)是不需要的

"必須要將fopen或者freopen放到所有變量定義的下面，否則會(huì)編譯錯(cuò)誤..."
C89是不能隨處定義自動(dòng)變量的，只能在函數(shù)開始，所有語句之前。
C99和C++允許使用前定義。
可能是C-free（好東西）默認(rèn)建的是C工程？


win下不是"CONIN$"與"CONOUT$"嗎？我記錯(cuò)了？


其實(shí)也可以這樣：
FILE* fin = fopen("in.txt","r"); /* or fin = stdin */
FILE* fout = fopen("out.txt","w"); /* or fout = stdout */

/*
使用fprintf(fout, format, ... ); fscanf(fin, format, ... );
*/

any會(huì)使用動(dòng)態(tài)內(nèi)存，效率比較低。而且，你也不希望看到如下代碼：
CSrcRelease ... 產(chǎn)生異常吧？

可以用function<void ()>來保存bind的結(jié)果，并在析構(gòu)函數(shù)中調(diào)用。
或者，使用Loki::ScopeGuard。

nelem是size_t類型，不是size_t*
不一定是升序，也可以是降序，跟fcmp參數(shù)有關(guān)。
(void*)&i,(void*)&a是不必要的，(const)T*到const void*的轉(zhuǎn)換可以是隱式的。

好像說偏題了……

chinaunix上討論時(shí)，他并沒有說是哪一題，只說有題目提示說要用scanf/printf。他自己也記不清楚是哪一題了。
2602是我自己找出來的，覺得這題比較變態(tài)。

如果樓主在做其他題目時(shí)，發(fā)現(xiàn)題目下面有提示說使用scanf/printf的話，還請(qǐng)通知我一下，謝謝~_~

同意cm的意見：緩存的層次越少越好。
真要做，就直接與VirtualAlloc, mmap, sbrk交互，不通過crt。


解決內(nèi)存碎片的算法除了垃圾收集以外，也是存在的。
但這個(gè)算法是要client端（內(nèi)存的使用者）配合才行。
如果內(nèi)存分配器對(duì)內(nèi)存的請(qǐng)求的方式一無所知，只靠猜測(cè)，這種generic內(nèi)存分配器已經(jīng)沒有提高余地了。
要繼續(xù)提高內(nèi)存分配效率，必須讓client告訴內(nèi)存分配器他會(huì)以何種方式使用內(nèi)存。內(nèi)存分配器根據(jù)不同的使用方式來優(yōu)化自己的算法。

例如，假設(shè)實(shí)現(xiàn)一種類似<<c interfaces and implementations>>中的arena，并且不通過crt，直接使用VirtualAlloc。當(dāng)arena被釋放的時(shí)候，確實(shí)就不存在任何碎片。

@iSsay
這個(gè)嘛，你去測(cè)吧，嘿嘿。


做2602的背景是這樣的：chinaunix上有人說poj上有題目建議使用scanf/printf，否則做不出來。
然后我就去試了試。 先隨便在網(wǎng)上扒了一份代碼，TLE……
干脆自己寫，用g++提交，結(jié)果就過了，換c++提交，第2次就跳到no1去了。
不過oj上的時(shí)間測(cè)不準(zhǔn)，精度太低。其他人多提交幾次可能也會(huì)沖到no1去。


iostream的格式化是靜態(tài)分派的，printf/scanf是動(dòng)態(tài)分派。
在格式化上，iostream的機(jī)制理論上的效率是會(huì)高而不是低。

iostream輸在格式化后的其他事情上去了。iostream下還有一層client可知的streambuf層次。

iostream多這一個(gè)層次，就將"格式化"與"緩沖"工作分開了。
你可以復(fù)用iostream的格式化功能，但給它一個(gè)不同于file的目的地，比如socket、memory、null —— 只要傳遞給它相應(yīng)的streambuf就行。

對(duì)于memory作為目的地，stl提供了stringbuf。并有相應(yīng)的stringstream在iostream上增加一些接口，使得client不用直接操縱stringbuf。
C標(biāo)準(zhǔn)庫相應(yīng)有sprintf,sscanf。但要這么看，sprintf不能擴(kuò)容。
類似的還有在我最開始接觸vector的時(shí)候，也覺得它慢。因?yàn)槲夷胿ector和固定大小數(shù)組比較。但當(dāng)我不做oj，數(shù)組大小不方便提前計(jì)算出時(shí)，怎么辦？
而且，stl其實(shí)還有strstream……

以socket作目的地？ printf/scanf怎么搞？
自己實(shí)現(xiàn)printf/scanf嗎？ 你覺得這容易嗎？
如果不自己實(shí)現(xiàn)printf/scanf，那就只能利用緩存。
拿這種情況和iostream + socketbuf比較，那才公平。

iostream還有很多亂七八糟的功能，locale，expcetion，callback，fillchar……

總之，在一個(gè)只處理build-in類型，數(shù)組/緩沖大小可以提前計(jì)算并按最大值提供，不需要按需提供/擴(kuò)展，不處理多語言的情況下 —— OJ的情況下 ——確實(shí)利用不了iostream,vector等提供的功能。
但OJ做多了，就反過來說它們的不是，就很扯蛋了。
說實(shí)話，OJ的代碼普遍是上不得臺(tái)面的，大家自己心里清楚。
根本就沒有一點(diǎn)點(diǎn)軟件工程的美感在里面。可復(fù)用嗎？不能，都是一次性筷子，完全是為了AC而已。

在實(shí)際開發(fā)中，沒有這么多美好的前提條件。

即使iostream功能比printf/scanf多得多，如果iostream的格式化比printf/scanf有數(shù)量級(jí)的差異，沒得說，那肯定是iostream實(shí)現(xiàn)得太爛……
同樣的是格式化和讀寫文件操作，多一個(gè)間接層次就導(dǎo)致效率數(shù)量級(jí)的下降？那不是寫得爛能是什么呢？找個(gè)好點(diǎn)的吧。
還有用VC6的OJ（非POJ），你能拿它怎么辦呢？

@iSsay
標(biāo)準(zhǔn)IO？cin,cout,cerr,clog不就是標(biāo)準(zhǔn)IO么？

你指的是formatted io？

@溪流
一個(gè)google帳號(hào)好像可以建5個(gè)項(xiàng)目。每個(gè)項(xiàng)目好像可以有2g空間。但是只能放和代碼相關(guān)的哦，否則被發(fā)現(xiàn)了google帳號(hào)會(huì)被禁用。

每個(gè)項(xiàng)目可以傳文件上去，比如打包好的代碼。

還有一個(gè)repository。原來只提供svn的，后來加入了hg。不過沒有加git。
svn的repository就是上面說的那樣，擁有者才有commit權(quán)限以及授權(quán)的權(quán)限。
普通用戶只有check out的權(quán)限。要么只看不改，要么找你要授權(quán)，要么給你發(fā)補(bǔ)丁。


自己機(jī)器上做一個(gè)svn repository的事…… 我也這樣干過……
所以很痛恨svn，所以打算用git。

@iSsay
就事論事而已，我不是大牛，pku上就沒過幾道題。
代碼里面有很多速度測(cè)試的代碼，所以很長。

其實(shí)是用istream::read 一次讀完所有輸入到buf。
將buf[0],buf[2],buf[4], ... 看作a
將buf[1],buf[3],buf[5], ... 看作b
然后高精度加高精度。
加法時(shí)沒有沒有轉(zhuǎn)換到0-9 直接用'0'-'9'計(jì)算，輸出時(shí)也省去了另一次轉(zhuǎn)換，直接輸出一個(gè)字符串。

木有

@溪流
別人只能check out不能commit。除非你授權(quán)。或者把補(bǔ)丁發(fā)給你。
用git吧，趨勢(shì)……

@iSsay
少扯了，uther是我臨時(shí)注冊(cè)的馬甲。

@溪流
嗯嗯，你說中了，炒作~_~
類似的還有很多……

"經(jīng)實(shí)踐,在大規(guī)模輸入輸出下,cin,cout效率遠(yuǎn)遠(yuǎn)低于scanf()和printf()"
遠(yuǎn)遠(yuǎn)低于？ 太夸張了……
野蠻人拿到打火機(jī)可能也會(huì)抱怨"還不如我的木頭"。

看看這個(gè)：
http://acm.pku.edu.cn/JudgeOnline/problemstatus?problem_id=2602

第1個(gè)uther的，就是用C++ iostream做的。

如果不加保護(hù)，兩種寫法都有可能產(chǎn)生2個(gè)實(shí)例。

書上采用第2種形式居多的原因，可能是因?yàn)镚of的書……
第1種形式是Scott Meyers后來發(fā)明的。

@溪流
你就沒領(lǐng)會(huì)后者的精妙~_~

后者的精妙之處在于：增加的東西不可能輕易拿掉 —— 否則會(huì)破壞舊有代碼。
反之，加入原本不存在的東西是很容易的事情……

如果某個(gè)功能確實(shí)很常用，你可以再得到這種反饋之后將其作為aux添加進(jìn)去。
反之，如果一開始就有某個(gè)設(shè)計(jì)糟糕的功能存在了，你得到反饋之后也很難將其去掉，并且還要一直維護(hù)這個(gè)糟糕設(shè)計(jì)…… 很惡心


我很欣賞lua的設(shè)計(jì)，將lua庫分為core和aux兩個(gè)層次，而不是混淆在一起。
加上client，總共就是3個(gè)層次。
保持core的精簡對(duì)維護(hù)是非常重要的。
aux本身實(shí)現(xiàn)就不難，多提供一些對(duì)維護(hù)影響不大。是否提供完全看需求 —— 這是否是很常見的一種使用方式。

以u(píng)nix的機(jī)制、策略論來說：core就僅僅提供機(jī)制，aux將一些常用策略打包，方便client使用。


設(shè)計(jì)之初就要考慮如何將core精簡到最小。這對(duì)日后維護(hù)是非常有幫助的。
一種精簡的大方向就是僅提供機(jī)制。比如vprintf_parse，就是一種機(jī)制。

客戶會(huì)如何使用它？就是策略了。客戶可以非常多的方式（dst不同）使用它。
可以預(yù)見：將string作為dst是一種很常見的使用策略。
仍然可以先不提供它…… 萬一這種估計(jì)錯(cuò)誤了呢-_-
如果估計(jì)正確，大量代碼的使用者向你抱怨"為什么不提供string.format?"，你再提供也來得及~

其他的精簡方式…… 再慢慢總結(jié)吧……

@溪流
1.
這是C++的缺陷…… 當(dāng)初可能沒想到模板會(huì)被這么用，所以模板的功能其實(shí)還比較弱。
即使比較弱，也比java和C#強(qiáng)大，它是真正的代碼生成器……
C#的模板有一些約束，java的根本就是垃圾……
所以，模板還是很復(fù)雜的……

更本質(zhì)的說，其實(shí)體現(xiàn)的是一種ducking type，以單一函數(shù)作為組件之間交互的接口，而不是整個(gè)類型。ruby、python、lua這種動(dòng)態(tài)類型語言都支持ducking type。而C++的模板只支持編譯時(shí)的ducking type。
C++社區(qū)給這種使用方式取了一個(gè)新的名字，叫concepts……

ducking type可能屬于新東西，而且很可能是意外產(chǎn)物（比如C++、python、lua；ruby好像是設(shè)計(jì)之初就考慮到這種用法），所以沒有提供專門的、顯示的通過短小的代碼（比如interface聲明）就可以表達(dá)的方式。只能通過文檔了……

說穿了，那些抵觸這種設(shè)計(jì)的，要么是偷懶不想看文檔，要么是已經(jīng)學(xué)會(huì)OO就不想學(xué)任何其他新事物，要么就是理解能力不夠……

心里疙瘩放下吧……
1.1. 雖然沒有專門的語法支持，但語言還是會(huì)檢查的，比如C++編譯時(shí)出錯(cuò)，其他3個(gè)語言運(yùn)行時(shí)出錯(cuò)。
1.2. 比如python標(biāo)準(zhǔn)庫中，序列就沒有單獨(dú)的size()成員。所有的序列都通過len得到長度。已經(jīng)開始向這種思想靠攏了。
1.3. stl也這么多年了……



2
我對(duì)0依賴的看法不是"難"，而是"通常沒有必要"。
應(yīng)該盡可能復(fù)用已有的優(yōu)秀的代碼。
盡可能向已有的，還過得去不算垃圾的標(biāo)準(zhǔn)靠攏，而不是自己獨(dú)立發(fā)明一套，結(jié)果在實(shí)際應(yīng)用中無法融合。

當(dāng)然，這和練習(xí)編程技巧相抵觸……
所以我想提出一些建議，既可以練習(xí)；并且練習(xí)的結(jié)果是可以真正派上用場(chǎng)的。

比如，你可以考慮實(shí)現(xiàn)這樣一個(gè)函數(shù)：
int vprintf_parse(void (*handler)(const char* s,void* context),void* context
const char* format, va_list arg );

按vprintf的標(biāo)準(zhǔn)去解析format與arg。每處理完一個(gè)%就調(diào)用handler一次。
由handler去考慮將s"輸出"到哪里。
這樣的話，vprintf_parse就可以用于很多很多地方：傳遞不同的hanlder給它就行。
當(dāng)然，你也可以用它來實(shí)現(xiàn)string.format。 但一定要將vprintf_parse暴露出來，否則窩在string.format中太暴殄天物了。


更進(jìn)一步…… 還可以提供一些讓客戶代碼擴(kuò)展的機(jī)制，讓它自己定義%后的轉(zhuǎn)義符，以及處理方式。



3
我的意思是，這種方式是行不通的。
你要插入的元素是T吧？
std::set<std::list<T> > 元素是 std::list<T> 哦， 不是T了。
比較也是按std::less<std::list<T> >比較，而不是T。

不管multiset的底層實(shí)現(xiàn)是rbtree還是rbtree+list，都需要真正定義一個(gè)類，將底層實(shí)現(xiàn)的接口adapt一下才行。僅僅typedef是不夠的……

再給你說個(gè)玄乎一些，不那么實(shí)際的理論吧……

一種設(shè)計(jì)傾向是"添加直到無法添加"。
一種設(shè)計(jì)傾向是"減少直到無法減少"。

我傾向于后者。也相信你寫過一些代碼之后會(huì)對(duì)前者感到反感。

1.
"盡管很“巧合”有幾個(gè)一樣的接口"
stl組件之間的通信就是通過這種"巧合"。


2.
為什么要零依賴？ 這個(gè)需求很怪……

想練習(xí)發(fā)明輪子的心情可以理解……
再給你提供一個(gè)練習(xí)而又不是重復(fù)發(fā)明的東西吧：
將printf和scanf的解析過程抽象出來。
這樣，string就只是管理內(nèi)存就可以了。
format交給別的地方去做。
相互之間保持正交。

這樣，format的src和dst可以是FILE*,socket, 以及任何可擴(kuò)展長度的順序結(jié)構(gòu)，比如各種string，std::vector,std::deque,std::list。
不要將format的功能"埋葬"到你那個(gè)string中，太可惜了。將它剝離出來。


還有stl中的反向迭代器其實(shí)是有單獨(dú)一個(gè)模板的，在<iterator>中，通常不需要自己手工編寫。
你可以重復(fù)發(fā)明它一次，然后應(yīng)用于你的各種容器之上，而不是重復(fù)發(fā)明多次。



3.
至少std::multiset<T>和 std::set<std::list<T> > 或 std::set<std::vector<T> > 語意都是不同的。

@溪流
好像是這樣的…… 很尷尬……

RbTree和Set還好一些，因?yàn)樗鼈兊慕涌诓灰欢ㄏ嗤赡苷娴男枰肦bTree實(shí)現(xiàn)Set，并增加或隱藏一些成員。

我以前遇到的情況是實(shí)現(xiàn)了一個(gè)allocator，然后想運(yùn)用到STL的容器當(dāng)中去，發(fā)現(xiàn)了這個(gè)問題……

下面這種想當(dāng)然的代碼行不通：
template<typename T>
typedef std::vector<T,my_allocator<T> > my_vector;

而且my_vector和vector行為完全相同。不像RbTree，本來就需要Set去adapt一下。比如下面3種代碼，都很惡心：

1.
template<typename T>
my_vector : public std::vector<T,my_allocator<T> > {};

2.
template<typename T>
my_vector : std::vector<T,my_allocator<T> > {
// forwarding functions
};

3.
template<typename T>
my_vector {
std::vector<T,my_allocator<T> > v_;
// forwarding functions
};


后來想想，算了，我的工作就是提供allocator，不負(fù)責(zé)為其取一個(gè)好聽的名字。
敢用allocator的人，肯定知道應(yīng)該這么用：
std::vector<his_element,my_allocator<T> > v; //一個(gè)使用了my_allocator的std::vector。
同樣工作得很好嘛。



相反，使用c++0x的功能，可能還會(huì)造成一些問題：
my_vector<int> v; // my_vector是什么東西？

哦，看到這些代碼，才能明白它是什么東西：
template<typename T>
using my_vector = std::vector<T,my_allocator<T>>;


這和typedef的誤用會(huì)過多引入不必要的概念是一個(gè)道理。

C++0x可以...
好像叫template alias

@bujiwu
map.erase有3個(gè)重載
...
返回iterator的erase是不符合STL標(biāo)準(zhǔn)的。

Windows還是linux沒有直接關(guān)系。于STL實(shí)現(xiàn)有直接關(guān)系。
map.erase有3個(gè)重載：
void erase ( iterator position );
size_type erase ( const key_type& x );
void erase ( iterator first, iterator last );

返回iterator的erase是不符合STL標(biāo)準(zhǔn)的。

DWORD GetProcessId(HANDLE process); ？？？

@空明流轉(zhuǎn)
謝謝~_~

請(qǐng)教一下：
"但是如果你使用、修改了別人LGPL協(xié)議的源代碼，那么，修改后的源代碼就必須要公開，并且一樣遵守LGPL協(xié)議。"

假設(shè)這樣一個(gè)場(chǎng)景，一個(gè)庫L，使用LGPL。
某個(gè)家伙，比如我吧，對(duì)這個(gè)庫作了一些修改，成為L1，并且使用L1做了一個(gè)應(yīng)用程序，叫A1。

必須公開的部分是L1，還是L1+A1 ？


我覺得后者好像說不過去。
因?yàn)槲铱偪梢詫⑽易龅氖虑榉殖?步：
1. 發(fā)布一個(gè)使用LGPL的L1 // 必須公開L1代碼
2. 使用LGPL的L1產(chǎn)生A1 // 貌似不必公開A1代碼？

是這樣嗎？ 謝謝~_~

代碼很好看。

GetN(int n)始終返回1？ 復(fù)制時(shí)弄錯(cuò)了？

@Little star
標(biāo)準(zhǔn)就這么規(guī)定的。

《C 語言常見問題集》 5.14中介紹了一些古怪的空指針。
“至少PL/I, Prime 50 系列用段07777, 偏移0 作為空指針。
……
CDC Cyber 180 系列使用包含環(huán)(ring), 段和位移的48 位指針。多數(shù)用戶
(在環(huán)11 上) 使用的空指針為0xB00000000000。
在舊的1 次補(bǔ)碼的CDC 機(jī)器上
用全1 表示各種數(shù)據(jù), 包括非法指針, 是十分常見的事情。
Symbolics Lisp 機(jī)器是一種標(biāo)簽結(jié)構(gòu), 它甚至沒有傳統(tǒng)的數(shù)字指針; 它使用
<NIL, 0> 對(duì)(通常是不存在的<對(duì)象, 偏移> 句柄) 作為C 空指針。
”

浮點(diǎn)如果是采用IEEE754， 0.0恰好是二進(jìn)制全0。
但標(biāo)準(zhǔn)沒有保證浮點(diǎn)數(shù)一定采用IEEE754。

@Little Star
class C {
/* data declaration */
public:
C() { memset(this,0,sizeof(*this); }
};

改為：
class C {
struct data {
/* data declaration */
} data_;
public:
C() { memset(&data_,0,sizeof(data_); }
};


還是需要注意memset( ... 0 ... );
不能保證： 指針是nullptr，浮點(diǎn)數(shù)是0.0, 0.0f, 0.0lf。
能保證：整數(shù)是0， 字符是null字符，即'\0'。

@codejie
STL有輸入、輸出、前向、雙向、隨機(jī)，5種迭代器。
erase有范圍刪除：
first = v.begin()+start;
v.erase( first, first+min(size,v.size()-start) );

沒有虛函數(shù)也不可以亂來。
空指針并不一定是二進(jìn)制全0。

1.
char* label = 0;

2.
char* label;
memset(&label,0,sizeof(label) );

有平臺(tái)上兩者功能不同。

暈……
v.erase(v.begin()+1);

1.要搜kbcwait4ibe，不要搜"虛擬鍵盤"。
2.以下劃線開始的標(biāo)識(shí)符是C/C++語言所保留的啊，同學(xué)們……

具備你說的那些能力后，想讀研又是麻煩事了……
會(huì)成天想著具備更多的能力，然后成績一塌糊涂……
學(xué)校是認(rèn)成績（以及關(guān)系）而不是能力的地方……

刪去最大最小值(O(1)) ???

刪除操作不包括shift？ 不shift的話，剩下的就不是堆了。
刪除操作包括shift，復(fù)雜度就是對(duì)數(shù)。

java的慢，不僅僅是在編譯上，而是在其內(nèi)存模型上。
即使有JIT也沒用，再優(yōu)化JIT也沒有用。除非修改其內(nèi)存模型。
但那是不可能的。

java效率媲美C/C++的實(shí)際例子：
要么是是在emulator層上跑C/C++代碼；
要么是例子過于簡單以體現(xiàn)不出java的缺陷；
要么兩者兼有。

說java效率可以C/C++媲美的人，要么是奸商，要么是sb。

哎…… 懶得批了……

有假設(shè)就寫到代碼里嘛。
隨便找個(gè)編譯單元：
static char assume[sizeof(header)==sizeof(u16)*3?1:-1];

或者就在header下方寫：
typedef int assume[sizeof(header)==sizeof(u16)*3?1:-1]];