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