一方面。。。
Windows的某些函數(shù)（忘記是哪些了。。。 應(yīng)該有CreateWindow） 確實(shí)會(huì)導(dǎo)致線程被額外分配一些內(nèi)容（也忘記是哪些了。。。比如消息隊(duì)列）。
Cookie也確實(shí)有Expires和Max-Age。

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


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

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

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

這些功能，需要這么多文件，以及這么多次鼠標(biāo)點(diǎn)擊！？才能實(shí)現(xiàn)？
當(dāng)然，我在這方面也是個(gè)菜，這也只是憑著對MS一貫的感覺來的。。。

@zuhd
cppblog的排版功能太弱了。。。 寫東西很費(fèi)勁。。。

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

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

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

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

本來應(yīng)該用高級(jí)評(píng)論將重點(diǎn)高亮的，但不知道cppblog出了什么問題用不了。只能眼睛尖點(diǎn)了。。。

1. test files

module.c 導(dǎo)出1個(gè)變量與3個(gè)函數(shù)

__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 輸出變量地址、函數(shù)地址以及函數(shù)包含的指令

#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)

查看反匯編與重定項(xiàng)
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條）指令的操作數(shù)（地址在10001001）是 10003000
1000100A 處（set的第2條）指令的操作數(shù)（地址在1000100B）也是 10003000
注意"File Type: DLL"，這是根據(jù)PE的域來的。

編譯并運(yùn)行得到的輸出是
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 恰好加載在首選基地址，所以沒有發(fā)生重定項(xiàng)。
要演示重定項(xiàng)發(fā)生的情況， 可以將 module.dll 復(fù)制一份， 然后用 LoadLibrary 加載。
或者直接首選基地址為一個(gè)會(huì)沖突的， exe的默認(rèn)基地址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 的輸出，可以發(fā)現(xiàn)指令中的操作數(shù)有相應(yīng)的修改，以正確的使用00393000上的變量error_code。


4. dll fixed

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

產(chǎn)生的dll里就沒有重定項(xiàng)信息
dumpbin /relocations module.dll

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

main.exe


5. exe export

默認(rèn)exe是不會(huì)包含重定項(xiàng)信息的
cl /O1 module.c && dumpbin /relocations module.exe

File Type: EXECUTABLE IMAGE

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

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

但是讓 main.c 鏈接到 module.exe 可以運(yùn)行成功（之前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。
如果真的調(diào)用了get和set，也只是讀寫了其他的地址，而不是error_code。
bug已經(jīng)產(chǎn)生了。 沒崩只是運(yùn)氣， 那個(gè)地址恰好有讀寫權(quán)限。
而且實(shí)驗(yàn)代碼一般都比較短，跑完馬上就退出了，這種意外的寫入產(chǎn)生的影響也不一定能發(fā)現(xiàn)。

6. exe export with relocation information

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

dumpbin /relocations module.exe 會(huì)產(chǎn)生很多輸出，因?yàn)樗€引用了libc。

而讓 main.c 鏈接到 module.exe 并運(yùn)行的同樣不會(huì)發(fā)生重定項(xiàng)
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*)隨便寫個(gè)什么地址 = 12; // 只要運(yùn)氣好，同樣不會(huì)立即崩潰。

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

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

@溪流
兩個(gè)都是dllexport。兩個(gè)函數(shù)產(chǎn)生的代碼都會(huì)用上error_code的地址。

鏈接產(chǎn)生這個(gè)dll/exe的時(shí)候，是很難確切地知道加載后該dll/exe的地址。同樣也很難確切知道error_code的地址，因?yàn)樗蚫ll/exe被加載后的基地址之間的偏移是鏈接后就固定了的。

于是鏈接器只能先假設(shè)dll/exe會(huì)被加載到某個(gè)位置（首選基地址），然后根據(jù)它產(chǎn)生代碼。

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

如果是dll，沒有被加載到首選基地址的話，就會(huì)發(fā)生重定項(xiàng)。set/get的指令會(huì)相應(yīng)的修改。
而exe，我記得loader就不會(huì)做這個(gè)工作，于是就。。。

@溪流
手誤。。。我的錯(cuò)。。。

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

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

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

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

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

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

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

@溪流
1, 2, 3逗號(hào)運(yùn)算符，最后轉(zhuǎn)型為void。

從后面的例子來看。。。 可能是為了讓那一整托東西是一個(gè)表達(dá)式。
你試試實(shí)現(xiàn)assert就能體會(huì)了。。。

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


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

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

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


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

例如， 就會(huì)出現(xiàn)某個(gè)函數(shù)Fi， 它接受到某個(gè)interface Ij， 但它需要interface Ik， 于是就只能 *運(yùn)行時(shí)查詢* ， 丟失了靜態(tài)類型檢測。

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

對實(shí)際稍微大一些的系統(tǒng)， 如果想讓demonstration展示出的漂亮設(shè)計(jì)延續(xù)下去， 需要的interface數(shù)目就會(huì)超出人的接受能力。demonstration演示不出這一點(diǎn)。

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



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

對那種需要?jiǎng)討B(tài)查詢，從interface Ij轉(zhuǎn)換到Ik的情況，QueryInterface什么的，真是無能為力。。。



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

脫離Python，更一般的情況來說，要達(dá)到"Fi對它的參數(shù)的要求*不多不少*， 參數(shù)能 *恰如其分* 的實(shí)現(xiàn)這些要求"的目標(biāo)， 并不一定需要 *隱式*， 也不一定需要Python那樣的動(dòng)態(tài)類型。
可以是顯式的、 靜態(tài)類型的， 例如Haskell。

使用interface的語言里，一個(gè)類型要實(shí)現(xiàn)什么interface在類型定義的時(shí)候就必須決定， 是另一個(gè)設(shè)計(jì)缺陷。 至少在C++/Java/C#里是這樣。
至于其他的靜態(tài)類型的OO語言。。。我學(xué)語言有個(gè)標(biāo)準(zhǔn)。。。 就是如果這語言強(qiáng)調(diào)自己是支持OO的， 那就不學(xué)。 所以其他靜態(tài)類型的OO語言也不知道。


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

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

啊，先跑個(gè)題。。。這文章是原創(chuàng)吧？有你的風(fēng)格。。。
但你發(fā)現(xiàn)沒有。。。這文章在cppblog里轉(zhuǎn)載了好幾個(gè)地方。。。
而且那幾爺子的blog最近都這樣，統(tǒng)一發(fā)同一篇文章。。。
之前還在想是不是有個(gè)是主號(hào)、其他是馬甲。。。 看來全都是馬甲嗎。。。


嗯，我關(guān)注的是這里： >> 這三個(gè)接口，連帶他們的父類，總共需要實(shí)現(xiàn)31個(gè)接口！不過還好，除了篇幅稍微長一點(diǎn)，基本上都是E_NOTIMPL。
想了解這種情況會(huì)不會(huì)經(jīng)常發(fā)生？

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

于是只能E_NOTIMPL啥啥的。。。

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

函數(shù)式編程沒專門看過什么數(shù)據(jù)……

PS：cppblog的通知郵件被gmail當(dāng)作垃圾了……

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，同樣不能確定它究竟做了什么。
完全被優(yōu)化掉了？
還是上下文中有重復(fù)計(jì)算，此處直接取的結(jié)果？
但有多少人是真正關(guān)心i+j具體被如何處理，實(shí)現(xiàn)的么？
絕大多數(shù)情況都不需要。

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


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


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

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

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

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

@溪流
另一種方式： 將那些退出測試點(diǎn)， 換成設(shè)置一個(gè)完成標(biāo)記。

退出測試：
發(fā)出的中止請求會(huì)"延遲"到執(zhí)行退出測試點(diǎn)時(shí)。
這個(gè)退出點(diǎn)之前的工作都是完成的， 余下的是放棄的。

完成標(biāo)記：
發(fā)出的中止請求會(huì)"立即" —— 可能也會(huì)有一些延遲， 但至少不會(huì)等待到下一個(gè)完成標(biāo)記 —— 執(zhí)行。
上一個(gè)完成標(biāo)記前的工作是完成的， 余下的是放棄的。

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

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

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

#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?
在其他線程上執(zhí)行 setjmp/longjmp... 太有意思了……
setjmp 到 longjmp 之間的C++代碼全得重寫…… 哇……

@溪流
恩， 我還覺得 loki.scopeguard應(yīng)該區(qū)分為
1. rollback 注冊的動(dòng)作可取消 —— loki.scopeguard實(shí)際實(shí)現(xiàn)
2. on_exit 注冊的動(dòng)作一定執(zhí)行 —— 其實(shí)這個(gè)用得不少

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

loki應(yīng)該是為了簡單吧， 一頂倆……

rollback函數(shù)本身就不應(yīng)該拋出異常。
異常安全的代碼依賴一些無拋出的代碼來執(zhí)行commit或者rollback。

所以：
1. 本來面目是還不了的
rollback動(dòng)作就應(yīng)該無拋出的執(zhí)行， 無論它本身是一個(gè)無拋出的函數(shù)， 還是被scopeguard的析構(gòu)所吞掉。

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

3. loki
loki應(yīng)該算是一個(gè)實(shí)驗(yàn)/教學(xué)性質(zhì)的庫吧？
所以盡可能的多傳授一些C++的知識(shí)， 比如"析構(gòu)絕對不能拋出異常"。
而沒太注重"該保證是誰的責(zé)任"。
所以就選擇一個(gè)簡單且效率稍微有點(diǎn)低的方案了。

用C++去對比lisp， 當(dāng)然會(huì)走彎路……

@溪流
嘿， 多謝理解~

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

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

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

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

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

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

其實(shí)我是覺得08很慢， 比05慢。
據(jù)用過10同學(xué)說， 10更慢……
如果公司要強(qiáng)制推行自家的新產(chǎn)品就有點(diǎn)過分了……

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

@空明流轉(zhuǎn)
gdb不一定有這個(gè)功能， 而且也不應(yīng)該有這個(gè)功能吧？
從VC6不支持來看， 也應(yīng)該是IDE實(shí)現(xiàn)的而不是windbg。

只要有耐心， emacs應(yīng)該是可以實(shí)現(xiàn)的。

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

學(xué)習(xí)鳥！！！

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

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

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

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

當(dāng)中還想過其他比較取巧的辦法……

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

這個(gè)是產(chǎn)生文檔的source：
http://simplejson.googlecode.com/svn/tags/simplejson-2.0.9/docs/_sources/index.txt

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


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

夠sexy吧？


但最終還是覺得會(huì)比較受限……
自己弄一個(gè)， 還可以順帶當(dāng)作練習(xí)……
反正也不急…… 慢慢弄……

看來得解釋一下……
我是有寫的， 還不少， 相當(dāng)?shù)亩啵?估計(jì)有4位數(shù)左右了。
只是沒發(fā)而已……


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


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


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


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


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


嗯， 就是這樣……

@yrj
>> 我想要知道的是每種方法的優(yōu)缺點(diǎn)和它的適用條件，應(yīng)用時(shí)根據(jù)不同的需求選擇適合的方法。

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

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

@yrj
孟巖的是吧？
當(dāng)時(shí)這篇文章在buzz上被分享是我就不予好評(píng)。
理由就是上面和cexer提到的， 完全的動(dòng)態(tài)， 純面向?qū)ο蠖皇敲嫦騝lass是有代價(jià)的， 而且是C++必定不能承受的代價(jià)。
只知道說C++這不好， 那不好， 也不想想為什么。
他的文章（至少C++相關(guān)那些）在我看來都是水多料少。
也許時(shí)代不同了吧……

@溪流
template <typename S>
class C;

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

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

"函數(shù)類型"是一個(gè)很灰色的地帶……

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

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

@溪流
舉個(gè)例子嘛……

不行就再舉個(gè)， 比如登錄， 批量下載圖片……
嗯， 就是校內(nèi)…… 我就是因?yàn)檫@個(gè)學(xué)python的。

最開始是打算用 libcurl， 但發(fā)現(xiàn)C/C++處理字符串太蛋疼……
又打算將 libcurl綁定到lua， 算練手（因?yàn)槟菚r(shí)候python還不熟）
最終發(fā)現(xiàn)還是麻煩， 直接用python了……

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

@溪流
嗯， 這是一個(gè)繞開的方法， 然后通過別的機(jī)制去獲得F的返回類型與參數(shù)列表還有調(diào)用約定。

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

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


但這對g++依然不行。
產(chǎn)生的兩個(gè)函數(shù)相互依然是重定義。

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

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

就是一些個(gè)人事務(wù)， 有重復(fù)與機(jī)械的味道， 而用C/C++去做太麻煩。