請(qǐng)教fanofvc如何拖網(wǎng)速的？
就是盡量使用其他辦法，而不是使用這些打洞的方法；只有沒有辦法的時(shí)候考慮一下，但不能一定保證成功
曾經(jīng)研究過，現(xiàn)在正在研究壓縮算法，下一步就是JPEG2000了
re: 代碼重構(gòu)-閱讀心得 笨笨 2006-08-16 11:38
不好意思，整理了
你看我翻譯的eMule的協(xié)議部分就可以理解了。
實(shí)際上在真正的P2P應(yīng)用中，使用UDP或TCP來在NAT上打洞的應(yīng)用很少見，我想原因有兩個(gè)：
1。可靠性不高，UDP雖然能夠，但如果碰到不是NAPT的轉(zhuǎn)換，也有些問題，TCP就不用說了，成功的可能性太小了。
2。由于這些P2P應(yīng)用中都有當(dāng)量的計(jì)算機(jī)存在，所以其中一部分肯定是有公網(wǎng)IP地址的，這個(gè)時(shí)候就不需要打洞了，主要是設(shè)計(jì)一個(gè)好的策略來使用這些有IP地址的計(jì)算機(jī)進(jìn)行傳輸。
我想你要是讀了eMule協(xié)議之后會(huì)更明白一點(diǎn)。
郵件的不能實(shí)時(shí)，不是很好
申請(qǐng)一個(gè)吧
還有一種理解就是，QA測(cè)試無數(shù)次，程序員修改無數(shù)次之后才保證的代碼能夠正常，沒有BUG的情況提前到來，在第一次由程序員將代碼交給QA的時(shí)候完成。我想大家不要光看題目，因?yàn)闆]有BUG是目標(biāo)，保證沒有BUG是過程。
對(duì)于kylin的問題，我想其實(shí)根本不用回答，因?yàn)镼A是為了找程序員的BUG，和程序員怎么樣保證自己沒有BUG，一點(diǎn)關(guān)系都沒有。
其實(shí)我這里不想和大家爭(zhēng)論什么是BUG或什么叫沒有BUG，關(guān)鍵在于寫程序的態(tài)度，如果作為一個(gè)程序員自己都認(rèn)為自己的程序有BUG，那么你不是合格的程序員或者說不是好的程序員。希望大家可以理解我的意思。
re: 全局變量的缺點(diǎn) 笨笨 2006-06-23 18:59
不要搞名詞戰(zhàn)爭(zhēng)啊
re: 全局變量的缺點(diǎn) 笨笨 2006-06-22 21:40
說的就是這個(gè)道理，關(guān)鍵看使用者對(duì)技術(shù)掌握的程度。
re: 全局變量的缺點(diǎn) 笨笨 2006-06-22 12:56
在C++中可以轉(zhuǎn)換為singleton，但也不能避免在多線程中的RE-ENTRY的問題;而C中就更不用說了
其實(shí)經(jīng)常在想自己同樣的缺點(diǎn)，怎么樣在逆境中仍然能夠發(fā)揮自己的全部確實(shí)是程序的標(biāo)志。
呵呵，你調(diào)式怎么辦？所以還必須區(qū)別對(duì)待
你說的很有道理，但有的時(shí)候，你從DLL得到一個(gè)BUFFER，然后你要使用他，但DLL根本不知道你什么時(shí)候釋放。當(dāng)然我們可以在DLL中提供一個(gè)API來專門用于釋放BUFFER，哈哈，不過總有不方便的地方。
而且如果采用這種辦法，我們根本不知道是采用的庫導(dǎo)致刪除BUFFER出問題的這個(gè)知識(shí)點(diǎn).
我沒有相關(guān)的程序
我想你因看一下IE是如何處理DRAG OVER等事件的,我試驗(yàn)發(fā)現(xiàn)他已經(jīng)是一個(gè)TARGET。
你的ACTIVEX control有窗口嗎？
呵呵，謝謝，這是及時(shí)翻譯的，所有有點(diǎn)亂，下次寫好一點(diǎn)
re: dynamic_cast介紹 笨笨 2006-03-30 20:10
dynamic_cast保證安全的轉(zhuǎn)換，因?yàn)槿绻怀晒Ψ祷氐氖荖ULL，而static_cast一般用于簡(jiǎn)單類型，對(duì)于復(fù)雜的向下轉(zhuǎn)換是不確定的
實(shí)際上這和：
1 void* mymemcpy( void* dest, const void* src, size_t count )
2 {
3 char* d = (char*)dest;
4 const char* s = (const char*)src;
5 do {
*d++ = *s++;
10
18 } while (count -- > 0) ;
20
21 return dest;
22 }
沒有本質(zhì)區(qū)別，僅僅循環(huán)的次數(shù)減少了。
有人說這個(gè)提高的效率，不知道提高在什么地方。
另外，我們也可以用4，16等任意數(shù)字來代替這里的8，當(dāng)然以方便處理為依據(jù)。
呵呵，看來你還沒有理解這個(gè)代碼。
我解釋一下：
n是我們需要循環(huán)的次數(shù)，我們的switch中有8個(gè)項(xiàng)，所以我們除8。
在count&7這個(gè)時(shí)候?qū)嶋H上這樣的count&0x111,我們僅僅取最低三位，也就是除8的余數(shù)，這可以保證，即使count不能被8整除也能處理多余的數(shù)據(jù)。
好了，現(xiàn)在回到循環(huán)，第一輪處理多余的部分（如果有），然后用N來控制循環(huán)次數(shù)
這里的case語句會(huì)從上到下一直執(zhí)行，因?yàn)闆]有break語句
最終可以保證我們需要的次數(shù)
re: TIFF圖像文件格式分析 笨笨 2006-03-22 08:36
什么叫純文本的東西？
re: TIFF圖像文件格式分析 笨笨 2006-03-10 16:23
壓縮？
re: TIFF圖像文件格式分析 笨笨 2006-03-09 19:29
2色的黑白灰度圖應(yīng)該和傳真的要求相似，不需要轉(zhuǎn)換，其他的就要自己來轉(zhuǎn)換了，轉(zhuǎn)換就按照數(shù)據(jù)存儲(chǔ)的方式來做。
如果轉(zhuǎn)換為黑白很簡(jiǎn)單（對(duì)于文字），將原來的24bit變成1
如果轉(zhuǎn)換為灰度的圖形，按照位圖到灰度圖的標(biāo)準(zhǔn)來變，到網(wǎng)上找找算法。
re: TIFF圖像文件格式分析 笨笨 2006-03-09 09:47
傳真文件應(yīng)該是黑白的圖就可以了，在不行就是灰度的圖。主要看是否支持彩色，即使是彩色的圖形，其bit也不會(huì)太高，需要轉(zhuǎn)換的。
當(dāng)然，我還不知道你的具體要求
re: 幾種壓縮算法原理介紹 笨笨 2006-03-08 17:03
呵呵，不是，是翻譯的！
我后來也看到了這個(gè)問題，遠(yuǎn)程線程是一方面，但修改導(dǎo)入節(jié)對(duì)于動(dòng)態(tài)調(diào)用的方式是不行的，需要取得GetProcAddress來得到地址，且跳轉(zhuǎn)。
picker說的有道理啊！我也試驗(yàn)了你的說法，完全可以。但我想這里是否符合MS的期望不是太重要，單獨(dú)繼承一個(gè)控件的好處是明顯的，代碼被分開處理了，控件只處理自身相關(guān)的東西，也就是其背景由其自身來話，更符合思維習(xí)慣了。謝謝你的建議，我有學(xué)習(xí)了一種新做法。
假牙，不具有通用性的輸出自身當(dāng)然好做，
增加 printf("%s",c);
printf("testttttttttttttt");
return 0;
就不行了
是的，實(shí)驗(yàn)成功了，上次放錯(cuò)了地方，放到生成后事件中就可以了，但這種情況適合那些只輸出的情況，如果需要moniter控制臺(tái)就不行了
re: 一個(gè)有意思的問題 笨笨 2005-11-12 21:21
哎，編譯器默認(rèn)是8個(gè)行不行呀？
請(qǐng)那位回復(fù)的朋友換個(gè)名字，有侮辱人之閑
說什么來？
突然對(duì)一件事情有領(lǐng)悟，記錄下來，希望與大家分享，僅次而已。
re: 一個(gè)有意思的問題 笨笨 2005-11-11 17:00
如果你是VC的話，使用
#pragma pack(push,8)
#pragma pack(1)//使用一個(gè)字節(jié)對(duì)齊
你在這里寫代碼
#pragma pack(pop,8)
這種情況不能亂用，因?yàn)闀?huì)降低效率
WINDOWS核心編程介紹字節(jié)對(duì)齊的原因
re: 一個(gè)有意思的問題 笨笨 2005-11-11 13:32
你的程序是按照8個(gè)字節(jié)對(duì)齊的