一方面。。。
Windows的某些函數（忘記是哪些了。。。 應該有CreateWindow） 確實會導致線程被額外分配一些內容（也忘記是哪些了。。。比如消息隊列）。
Cookie也確實有Expires和Max-Age。

某些庫、框架里的各種概念（UI線程，進程共享Cookie）的起源也許就源自這些區別。這些庫的作者（很有可能）清楚這些區別。
在MFC或WinINet（這是個啥東西。。。）的上下文中說這些自創的概念也應該沒什么問題。
無意間忘記帶上術語的上下文也情有可原。。。


而另一方面。。。
確實存在很多人，對更專有的概念與更一般的概念不加區分，甚至自以為是，甚至還以此嘲笑他人。。。
對這種井底之娃，你能拿他們怎么辦嘛。。。

怎么開始做這方面的事了？

話說，php,jsp還有你這里演示的一些asp代碼。。。 不都是一回事么。。。
都是在html里增加一些標記。。。 給人的感覺不好。。。

這些功能，需要這么多文件，以及這么多次鼠標點擊！？才能實現？
當然，我在這方面也是個菜，這也只是憑著對MS一貫的感覺來的。。。

@zuhd
cppblog的排版功能太弱了。。。 寫東西很費勁。。。

@zuhd
我記得是只與文件類型（PE中的那個域）有關，與加載方式（隱式加載/顯式加載）無關。

只要文件類型是exe，加載器就不會去處理重定項。
如果exe沒有加載到首選基地址，里面的指令操作的就不是預想中的地址。

前面說loadlibrary的意思是：這是一種讓dll/exe無法加載到首選基地址的方法。
如果將dll/exe文件復制一份（文件各種信息都是相同的），然后用loadlibrary加載這兩者，那兩者之一肯定之多有一個是被加載到首選基地址。于是就可以觀察另一個的情況了。

但前面為了偷懶。。。 就沒有用這個方法，而是用/base:0x400000 —— 這個是exe文件默認的基地址 —— 讓dll無法加載到首選基地址。

本來應該用高級評論將重點高亮的，但不知道cppblog出了什么問題用不了。只能眼睛尖點了。。。

1. test files

module.c 導出1個變量與3個函數

__declspec(dllexport) int error_code;
__declspec(dllexport) int get(void) { return error_code; }
__declspec(dllexport) void set(int x) { error_code = x; }
int main(void) { return 0; }

main.c 輸出變量地址、函數地址以及函數包含的指令

#include <stdio.h>

__declspec(dllimport) int error_code;
__declspec(dllimport) int get(void);
__declspec(dllimport) void set(int x);

int main(void)
{
int i;
unsigned char const* p;

printf("%p\n", (void*)&error_code);

p = (unsigned char*)get;
printf("%p:", p);
for (i=0; i<12; ++i) printf(" %02X", p[i]);
printf("\n");

p = (unsigned char*)set;
printf("%p:", p);
for (i=0; i<12; ++i) printf(" %02X", p[i]);
printf("\n");

return 0;
}


2. dll

編譯
cl /LD /O1 module.c /link /noentry

查看首選基地址
dumpbin /all module.dll | find /i "image base"
10000000 image base (10000000 to 10004FFF)

查看反匯編與重定項
dumpbin /disasm /relocations module.dll

File Type: DLL

10001000: A1 00 30 00 10 mov eax,dword ptr ds:[10003000h]
10001005: C3 ret
10001006: 8B 44 24 04 mov eax,dword ptr [esp+4]
1000100A: A3 00 30 00 10 mov dword ptr ds:[10003000h],eax
1000100F: C3 ret

BASE RELOCATIONS #4
1000 RVA, C SizeOfBlock
1 HIGHLOW 10003000
B HIGHLOW 10003000

10001000 處（get的第1條）指令的操作數（地址在10001001）是 10003000
1000100A 處（set的第2條）指令的操作數（地址在1000100B）也是 10003000
注意"File Type: DLL"，這是根據PE的域來的。

編譯并運行得到的輸出是
cl main.c module.lib && main.exe
10003000
10001000: A1 00 30 00 10 C3 8B 44 24 04 A3 00
10001006: 8B 44 24 04 A3 00 30 00 10 C3 00 00

error_code的地址和指令中使用的地址是相同的。


3. dll relocation

上面 module.dll 恰好加載在首選基地址，所以沒有發生重定項。
要演示重定項發生的情況， 可以將 module.dll 復制一份， 然后用 LoadLibrary 加載。
或者直接首選基地址為一個會沖突的， exe的默認基地址0x400000。

cl /LD /O1 module.c /link /noentry /base:0x400000

dumpbin /all module.dll | find /i "image base"
400000 image base (00400000 to 00404FFF)

dumpbin /disasm /relocations module.dll
00401000: A1 00 30 40 00 mov eax,dword ptr ds:[00403000h]
00401005: C3 ret
00401006: 8B 44 24 04 mov eax,dword ptr [esp+4]
0040100A: A3 00 30 40 00 mov dword ptr ds:[00403000h],eax
0040100F: C3 ret

BASE RELOCATIONS #4
1000 RVA, C SizeOfBlock
1 HIGHLOW 00403000
B HIGHLOW 00403000

cl main.c module.lib && main.exe
00393000
00391000: A1 00 30 39 00 C3 8B 44 24 04 A3 00
00391006: 8B 44 24 04 A3 00 30 39 00 C3 00 00

對比 dumpbin 得到的反匯編與 main.exe 的輸出，可以發現指令中的操作數有相應的修改，以正確的使用00393000上的變量error_code。


4. dll fixed

如果鏈接時選擇基地址固定
cl /LD /O1 module.c /link /noentry /base:0x400000 /fixed

產生的dll里就沒有重定項信息
dumpbin /relocations module.dll

并且選擇的是一個肯定會沖突的基地址，所以加載main.exe就會失敗。

main.exe


5. exe export

默認exe是不會包含重定項信息的
cl /O1 module.c && dumpbin /relocations module.exe

File Type: EXECUTABLE IMAGE

注意"File Type: EXECUTABLE IMAGE"，這是根據PE的域來的。

并且首選基地址也是沖突的。
dumpbin /all module.exe | find /i "image base"
400000 image base (00400000 to 0040BFFF)

但是讓 main.c 鏈接到 module.exe 可以運行成功（之前dll fixed的情況是加載 main.exe 失敗）
cl main.c module.lib & main.exe
0039B700
00391000: A1 00 B7 40 00 C3 8B 44 24 04 A3 00
00391006: 8B 44 24 04 A3 00 B7 40 00 C3 33 C0

注意指令里的操作碼，并沒有修改為error_code的地址：0039B700。
如果真的調用了get和set，也只是讀寫了其他的地址，而不是error_code。
bug已經產生了。 沒崩只是運氣， 那個地址恰好有讀寫權限。
而且實驗代碼一般都比較短，跑完馬上就退出了，這種意外的寫入產生的影響也不一定能發現。

6. exe export with relocation information

可以用 /fixed:no 附帶上重定項信息
cl /O1 module.c /link /fixed:no

dumpbin /relocations module.exe 會產生很多輸出，因為它還引用了libc。

而讓 main.c 鏈接到 module.exe 并運行的同樣不會發生重定項
cl main.c module.lib & main.exe
0039B700
00391000: A1 00 B7 40 00 C3 8B 44 24 04 A3 00
00391006: 8B 44 24 04 A3 00 B7 40 00 C3 33 C0

@zuhd
沒有崩潰=沒有問題=程序正確？

*(int*)隨便寫個什么地址 = 12; // 只要運氣好，同樣不會立即崩潰。

@溪流
另外，load是不會根據dll/exe后綴名來判斷是否是dll還是exe。
它是根據pe格式中的一個域來判斷的。具體位置我忘了。。。不過dumpbin好像能顯示出來。

也就是說。。。很多那些后綴是exe（甚至是ocx什么的），而且加載后也能成功調用里面函數的文件，其實按pe格式來說都是dll文件，只是后綴名沒有用dll而已。

@溪流
兩個都是dllexport。兩個函數產生的代碼都會用上error_code的地址。

鏈接產生這個dll/exe的時候，是很難確切地知道加載后該dll/exe的地址。同樣也很難確切知道error_code的地址，因為它和dll/exe被加載后的基地址之間的偏移是鏈接后就固定了的。

于是鏈接器只能先假設dll/exe會被加載到某個位置（首選基地址），然后根據它產生代碼。

比如一種極端情況，將dll/exe復制一份本地文件（首選基地址相同），然后loadlibrary它倆。
那么，至少有一個dll/exe是無法被加載到首選基地址的，也就是set/get的指令中使用的地址是不正確的。

如果是dll，沒有被加載到首選基地址的話，就會發生重定項。set/get的指令會相應的修改。
而exe，我記得loader就不會做這個工作，于是就。。。

@溪流
手誤。。。我的錯。。。

exe和dll還是有很多區別的。
首先entrypoint肯定就被忽略了。
其次重定位和依賴加載好像也會有問題。

比如試試這個？
int error_code;
__declspec(dllexport) int get_error(void) { return error_code; }
__declspec(dllimport) void set_error(int x) { error_code = x; }

get和set產生的指令里會有error_code的地址。
如果是dll，加載時指令中的地址會被正確地重定位。
而exe不行，即使保留重定位信息也不行。

exe可以被加載應該是為了里面的資源而不是代碼。

@溪流
嗯，如果表達式的值被設計為沒有意義的話，就可以(void)，避免被使用。

@溪流
不一定是不care，有可能是不能勝任。雖然結果都一樣，但不能與不愿的原因可是有區別的。

OO確實更簡單、更natural，對看不出person.learn(language)與learn(person, language) 是一回事的人來說的話。

@溪流
1, 2, 3逗號運算符，最后轉型為void。

從后面的例子來看。。。 可能是為了讓那一整托東西是一個表達式。
你試試實現assert就能體會了。。。

@溪流
至于躲開的技巧。。。 其實事情起因是這樣。。。
大概08-10年我就在cppblog或者CU（不記得是哪個地方了，又或者都有說）上說interface存在的問題。


一個函數f，它對它的參數有一些要求，例如你的代碼中不是E_NOTIMPL那些。 而不同的函數對它的參數有不同的需求。

但interface的問題就是，它不能直接描述某函數Fi的需求， 它一定需要一個 **打包** 的過程。

那這個打包的粒度是否恰當，以相信interface是解決問題的方案的人自身的說法， 就看 *設計師(架構師)* 的本事了。
他們還會傳授一些經驗技巧， 比如"每個interface包含3-5個method比較合適"什么的， 笑死人了。


以我這種不相信interface是解決問題的方案的人來看， 那些展現漂亮的設計的demonstration，也只能在demonstration里維持它的漂亮。
隨著系統滾大， interface就不能恰如其分的描述出需求。

例如， 就會出現某個函數Fi， 它接受到某個interface Ij， 但它需要interface Ik， 于是就只能 *運行時查詢* ， 丟失了靜態類型檢測。

不是 *架構師* 的設計失誤， 而是他要在 *讓每個interface Ij都能盡量恰到好處的描述出它使用者Fk 的需求* 與 *讓總的interface數目維持在一個可接受的范圍內* 之間作一個 *權衡* 。

對實際稍微大一些的系統， 如果想讓demonstration展示出的漂亮設計延續下去， 需要的interface數目就會超出人的接受能力。demonstration演示不出這一點。

這是interface本身的缺陷 —— 需要將一組需求打包（還有其他很多， 先不說了。。。）。 架構師只能緩解， 沒法解決。



對E_NOTIMPL，其實在C++里還好。。。 因為C++支持多繼承。。。
讓父類提供默認實現， 子類只override需要的便是。。。 而Java那種單繼承就完蛋了。
只是不知道為什么IOleXXX沒有這樣設計。

對那種需要動態查詢，從interface Ij轉換到Ik的情況，QueryInterface什么的，真是無能為力。。。



反觀duck typing —— 記得你也用Python的吧 —— 就沒有這樣的限制。
只要實現一個class， 讓它支持那些不是返回E_NOTIMPL的method就完了。
甚至都不需要IOleXXX或者QueryInterface這些概念。
每個函數Fi對它的參數們的要求雖然是 *隱式的*， 但卻是 *精確的*， 不多不少。

脫離Python，更一般的情況來說，要達到"Fi對它的參數的要求*不多不少*， 參數能 *恰如其分* 的實現這些要求"的目標， 并不一定需要 *隱式*， 也不一定需要Python那樣的動態類型。
可以是顯式的、 靜態類型的， 例如Haskell。

使用interface的語言里，一個類型要實現什么interface在類型定義的時候就必須決定， 是另一個設計缺陷。 至少在C++/Java/C#里是這樣。
至于其他的靜態類型的OO語言。。。我學語言有個標準。。。 就是如果這語言強調自己是支持OO的， 那就不學。 所以其他靜態類型的OO語言也不知道。


扯了一大通。。。 其實是想說。。。
我以前只是 *預感* interface的設計在稍微大一點的系統里就會出問題。
但對使用interface的大的系統都沒有研究的興趣。。。 看著頭就痛。。。 因此說明這問題的 *實際例子* 比較匱乏。。。
于是看到你的文章就有興趣了。。。 "看吧，我果然是對的！" <- 心聲大致是這樣。

@溪流
>> 不知道轉載了，搜一下先^_^~
我是訂閱了cppblog的所有文章、首頁原創、還有有幾爺子的單獨的。。。
所以不用搜就知道這個事。。。
但最近這種同一文章在所有文章里出現4-5次，首頁原創里出現4-5次，那幾爺子的單獨的rss里再出現4-5次。。。 吃不消啊。。。

啊，先跑個題。。。這文章是原創吧？有你的風格。。。
但你發現沒有。。。這文章在cppblog里轉載了好幾個地方。。。
而且那幾爺子的blog最近都這樣，統一發同一篇文章。。。
之前還在想是不是有個是主號、其他是馬甲。。。 看來全都是馬甲嗎。。。


嗯，我關注的是這里： >> 這三個接口，連帶他們的父類，總共需要實現31個接口！不過還好，除了篇幅稍微長一點，基本上都是E_NOTIMPL。
想了解這種情況會不會經常發生？

就是說，父類定義了N個虛函數（是純虛嗎？其實是不是都無所謂）。子類override之，然后傳遞一個子類到某個地方。但其實傳遞進去的子類，它們的那N個虛函數中只有少部分被調用。

于是只能E_NOTIMPL啥啥的。。。

@西月弦
Haskell我也是新手，感覺收獲最大的是 http://learnyouahaskell.com/
其次是 http://www.haskell.org/tutorial/ 內容不多，但信息量很大……
real world haskell對語言的介紹根本不夠看懂它里面提供的代碼……

函數式編程沒專門看過什么數據……

PS：cppblog的通知郵件被gmail當作垃圾了……

lastButOne xs = case xs of { [] -> Nothing ; y:[] -> Nothing ; x:y:[] -> Just x ; x:xs -> lastButOne xs}

或者：
lastButOne [] = Nothing
lastButOne y:[] = Nothing
lastButOne x:y:[] = Just x
lastButOne x:xs = lastButOne xs


《real world haskell》不怎么講語言的……

炮姐好……

@ＵＧＰ
joel這篇文章足以暴露他思維層次太低。


即使是在C語言中，對i+j，同樣不能確定它究竟做了什么。
完全被優化掉了？
還是上下文中有重復計算，此處直接取的結果？
但有多少人是真正關心i+j具體被如何處理，實現的么？
絕大多數情況都不需要。

那為什么對C++，就要求了解i+j是具體在干什么呢？
做出這樣批評的人，都是 *只懂得C級別的抽象方式，不懂得C++級別的抽象方式* 而已。


對異常也是如此。
對自己熟悉的方式根深蒂固，以至于根本就無法恰當分析其他方式。
他的批評，比如讓代碼難以理解，熟悉異常的人的眼中完全不可理解。


而匈牙利更是扇自己嘴巴。
他要的就是將safe與unsafe字符串通過某種方式告訴編譯器。
比如用不同類型，限制它們之間的自由轉換，轉換只能通過可控制的有限方式。
然后，讓 *編譯器自動地完成這樣的檢測* ，而不是什么手工肉眼去比。

@stepinto
上面有條回復正中要害：
>> 結論：google禁止異常比較省錢。

那么，你們禁止使用（了解）異常（以及其他各種技術）是為了什么呢？
為了當你所說的那種
>> 水平并不那么出色的開發者
對嗎？ 你就甘愿當這種拖后腿的人，是嗎？

>> 可以看一下exceptional C++的第二章，然后再來這里發言吧。
不好意思，整個exceptional系列我都看過好多年了。
你想得到的與想不到的C++書籍我都看過。
你想得到的與想不到的C++技術我都玩過。
所以我才看不起你們這種 *為自己的無能找借口* 的人。

@溪流
另一種方式： 將那些退出測試點， 換成設置一個完成標記。

退出測試：
發出的中止請求會"延遲"到執行退出測試點時。
這個退出點之前的工作都是完成的， 余下的是放棄的。

完成標記：
發出的中止請求會"立即" —— 可能也會有一些延遲， 但至少不會等待到下一個完成標記 —— 執行。
上一個完成標記前的工作是完成的， 余下的是放棄的。

就看你的工作是否能分開了……
比如， 數據如果是行為單位， 就可以寫一行后增加行計數。
行計數前的數據是有效的。
如果數據是， 比如xml， 那就完蛋……

@楊粼波
lz需要的應該是"被其他線程中止"， 而不是"自主中止" —— 否則直接return不就完了？
coroutine 是自主切換的， COoperate。

@溪流
哦， 你還想要 "安全的退出點" 啊？
你想想這兩種需求是否是矛盾的……
1. 只在一些點上可退出
2. 代碼中在這些點上又不要顯式寫出測試

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

DWORD CALLBACK infinite(void* arg) { for (;;) Sleep(0); return 0; }
void cancel(void) { ExitThread(12); }

int main(void)
{

DWORD tid = 0;
HANDLE thread = CreateThread(NULL, 0, infinite, 0, 0, &tid);
CONTEXT ctx = {0};
ctx.ContextFlags = CONTEXT_ALL;
SuspendThread(thread);
GetThreadContext(thread, &ctx);
ctx.Eip = (DWORD)cancel;
SetThreadContext(thread, &ctx);
ResumeThread(thread);
WaitForSingleObject(thread, INFINITE);
GetExitCodeThread(thread, &tid);
CloseHandle(thread);
return (int)tid;

}

SetThreadContext/GetThreadContext?
在其他線程上執行 setjmp/longjmp... 太有意思了……
setjmp 到 longjmp 之間的C++代碼全得重寫…… 哇……

@溪流
恩， 我還覺得 loki.scopeguard應該區分為
1. rollback 注冊的動作可取消 —— loki.scopeguard實際實現
2. on_exit 注冊的動作一定執行 —— 其實這個用得不少

將 loki.scopeguard 用于 on_exit 的情況很浪費啊……
需要開辟局部變量， 需要 if 測試， 而且這個測試代碼是在每一個退出點產生的……
這些開銷根本不需要的。

loki應該是為了簡單吧， 一頂倆……

rollback函數本身就不應該拋出異常。
異常安全的代碼依賴一些無拋出的代碼來執行commit或者rollback。

所以：
1. 本來面目是還不了的
rollback動作就應該無拋出的執行， 無論它本身是一個無拋出的函數， 還是被scopeguard的析構所吞掉。

2. scopeguard是否應該插手
我也認為它多管閑事了。
無拋出是rollback函數自身的責任。
沒有無拋出保證就不能稱為一個rollback。
應該努力將其寫為rollback， 然后scopeguard僅僅考慮注冊而已。
對實在沒有時間與精力寫為無拋出的rollback， 可自行吞掉：
rollback_nothrow(...) { rollback(...) }
makeguard(rollback_nothrow, ...)

3. loki
loki應該算是一個實驗/教學性質的庫吧？
所以盡可能的多傳授一些C++的知識， 比如"析構絕對不能拋出異常"。
而沒太注重"該保證是誰的責任"。
所以就選擇一個簡單且效率稍微有點低的方案了。

用C++去對比lisp， 當然會走彎路……

@溪流
嘿， 多謝理解~

@陳梓瀚(vczh)
vc6確實對C++確實有點過分了。
那改成如果發布C++， 用VC8的sln， VC9,10都可以編譯。
如果發布C， 那用VC6的dsw， VC6,8,9,10都可以編譯。

@陳梓瀚(vczh)
硬件當然再進步， 可以換更快的。
但這和更新軟件是兩碼事。

有更快的硬件， 不是"我們就應該用更消耗硬件資源軟件"的理由吧？

@溪流
對于編輯C/C++來說， 除了慢， 沒發現08比05有什么新功能……
對于發布來說， 發布一個VC6的dsw， 用戶只要不低于VC6， 他就能編譯。
高版本的IDE有從低版本工程文件導入的功能， 反之沒有……

@溪流
在足夠牛b的機器上 eclipse netbeans也不慢， 你用嗎~

@陳梓瀚(vczh)
貌似08和05的sln格式區別就只有第1行？

其實我是覺得08很慢， 比05慢。
據用過10同學說， 10更慢……
如果公司要強制推行自家的新產品就有點過分了……

如果只是開發C/C++， 不涉及.net和html什么的， 08、10完全沒優勢？
如果要用C++0x， 可以用單獨的cl16， IDE還是用05……
我就只下了cl16， 沒有VS10的IDE……

@空明流轉
gdb不一定有這個功能， 而且也不應該有這個功能吧？
從VC6不支持來看， 也應該是IDE實現的而不是windbg。

只要有耐心， emacs應該是可以實現的。

@陳梓瀚(vczh)
這人的名字真詭異……
BTW， 微軟內部使用VS是怎么算的？ 也需要"購買"什么的么？
會被強制使用最新版本么？ 2010？

學習鳥！！！

@溪流
>> 像是……帶版本控制的wiki？
嗯， 不過自動化程度不如wiki……
但使用的標記語言不受限制， 總之最后能產生html就行了。

@陳梓瀚(vczh)
忍不住， 手會癢……

@陳梓瀚(vczh)
msn的writer？ live writer？ 微軟那個？
試過一小會…… 貌似也是用metablog api來發表post。

而且不習慣富文本編輯…… 可能代碼寫慣了……
純文本， 可以啪啪啪啪胡亂寫一堆， 把腦袋里的東西先倒出來， 再慢慢整理。
而富文本， 總是忍不住一邊編輯， 一邊就去調整格式了……
純文本感覺對編程也友好一些， 如果原始標記不夠用， 可自己添加個預處理什么的； 而二進制格式文檔如果功能不夠用， 就只好干瞪眼了……

當中還想過其他比較取巧的辦法……

比如， 看這個： http://simplejson.googlecode.com/svn/tags/simplejson-2.0.9/docs/index.html

這個是產生文檔的source：
http://simplejson.googlecode.com/svn/tags/simplejson-2.0.9/docs/_sources/index.txt

語法是上面提到的rst， 用的sphinx。


將blog當作一個project：
1. 純文本編寫
2. 可diff
3. 版本控制之下
4. 評論什么的， project會提供code review, issue track, rss, email notify等功能

夠sexy吧？


但最終還是覺得會比較受限……
自己弄一個， 還可以順帶當作練習……
反正也不急…… 慢慢弄……

看來得解釋一下……
我是有寫的， 還不少， 相當的多， 估計有4位數左右了。
只是沒發而已……


沒發的原因是感覺cppblog不夠給力……
其實， 相比我寫文章的方式， emacs+rst ，我試過的所有blog的在線編輯器都不夠給力……
如果真用blog的editor， 也肯定寫不了那么多， 思路會被擾亂的……


也想過用metablog api， 將線下的文檔發上來； 但估計格式什么的還是會不滿意。
所以我想自己搭一個blog， 而不是用現有的blog服務， 那樣的話， 可控制的范圍要大得多， 可以較少的受制于人……


我已經在動手了…… 去年圣誕節申請了gae。
但我對網絡方面的東西一竅不通…… 冬天手也動壞了…… 敲鍵盤比較痛……
再加上各種亂七八糟的事……
估計要折騰相當長一陣子……


現在想法是先作為一個放文檔， 并有永久鏈接的地方。
索引、 評論、rss、 代碼高亮、 這些功能慢慢加……
似乎就這些功能比較重要？


也不想用Django或者micolog這樣的東西， 不然早就投奔wordpress什么的去了……
就是希望借這個機會（上面說了， 這方面能力幾乎為零）， 自己動手從零開始構建， 嗯， 造個輪子……
反正是我自己用， 造成方的也不會害到其他人……


嗯， 就是這樣……

@yrj
>> 我想要知道的是每種方法的優缺點和它的適用條件，應用時根據不同的需求選擇適合的方法。

嗯， 這是王道。
根據問題選合適的方案， 而不是將自己熟悉的方案去套各種問題。

關鍵是， 孟巖只提一方面（靈活性） 不提其代價。 片面的給C++抹黑。
仿佛能給C++抹黑就顯得自己多高水平似的。

@yrj
孟巖的是吧？
當時這篇文章在buzz上被分享是我就不予好評。
理由就是上面和cexer提到的， 完全的動態， 純面向對象而不是面向class是有代價的， 而且是C++必定不能承受的代價。
只知道說C++這不好， 那不好， 也不想想為什么。
他的文章（至少C++相關那些）在我看來都是水多料少。
也許時代不同了吧……

@溪流
template <typename S>
class C;

template <typename R>
class C<R (__stdcall*)()> {};

template <typename R>
class C<R (__stdcall&)()> {};

"函數類型"是一個很灰色的地帶……

就批量下載圖片這個case來說， C++能提高什么效率？
網絡傳輸才是大頭， 這C++是提升不了的。
也就提高解析html的效率…… 但那是多么蛋疼的事情……

5秒傳輸是死的。
0.5秒python解析， 與0秒（算極端情況）C++解析
體會不到差異……

@溪流
舉個例子嘛……

不行就再舉個， 比如登錄， 批量下載圖片……
嗯， 就是校內…… 我就是因為這個學python的。

最開始是打算用 libcurl， 但發現C/C++處理字符串太蛋疼……
又打算將 libcurl綁定到lua， 算練手（因為那時候python還不熟）
最終發現還是麻煩， 直接用python了……

嗯， wget 什么的我不熟……
用python做也算順便練習吧……

@溪流
嗯， 這是一個繞開的方法， 然后通過別的機制去獲得F的返回類型與參數列表還有調用約定。

在我的那個case里， 返回類型、參數列表、調用約定都要獲取， 并對不同的調用約定做不同的事。
嗯， 就是thunk啦， 你懂的。

最終還是要獲取那些信息， 所以我直接用
template<R>
R call ( R (*f) )
來獲取了。 這機制叫啥名一下子想不起來了……


但這對g++依然不行。
產生的兩個函數相互依然是重定義。

@溪流
誤會誤會…… 我說的"日常"是指工作飯碗以外的……

比如， 用metablog 轉移blog文章， 好像就是你寫過的吧？
這用C/C++就蛋疼了……

就是一些個人事務， 有重復與機械的味道， 而用C/C++去做太麻煩。