學(xué)習(xí)了

1、打包人員不該偷懶，他們應(yīng)該知道完整的精確的文件清單，而不僅僅是“某個目錄下的所有文件”
2、還是沒有看出來把solution單獨(dú)藏在一個目錄的用意。

個人非常討厭什么 bin，source，solution，。。。
你要么就純粹自己搞，bin、source 都可以，就別 solution、project 了，最后自己寫腳本
要么就用 solution、project，目錄就大體上按默認(rèn)的，一個project一個目錄，
既用 solution、project，又獨(dú)立搞一套目錄體系，然后修改一大堆純粹關(guān)于目錄的配置參數(shù)，何必呢

僅僅以快或慢來決定用哪個我覺得不好
這兩個函數(shù)的語義是不同的，要看上下文中你要操作的究竟是字符串還是普通內(nèi)存。就算沒法區(qū)分這一點(diǎn)，快慢也并非唯一標(biāo)準(zhǔn)，可能還有一些因素是重要的。
（抱歉，最近有點(diǎn)排斥“唯性能主義”。）

返回的不是臨時對象的引用。
之所以 warining，是因為 m_pB 會隨著 C 對象的析構(gòu)而消亡，此時，之前有這個返回的引用就成了孤魂野鬼了。m_pB 在類外的地位就是一個局部變量。

@flyinghearts
是的，應(yīng)該顯式轉(zhuǎn)換，但是我必須知道原始返回類型后，才能考慮如何轉(zhuǎn)換得到的結(jié)果。當(dāng)我寫下min(1LL, 2.0f) 的時候，我該認(rèn)為返回類型是什么呢？或者是你假定不允許寫下min(1LL, 2.0f)？請注意，當(dāng)寫下“min(1LL, 2.0f)”的時候，我并不了解min內(nèi)部做了什么，我只是認(rèn)為在比較他們的大小，不會猜到min里面會進(jìn)行類型轉(zhuǎn)換，因此不會寫成“min((float)1LL, 2.0f)”或者“min(1LL, (long long)2.0f)”。

對內(nèi)建類型來說，sizeof 誰大就轉(zhuǎn)到誰，也不是最合理的
比如int->double，我認(rèn)為應(yīng)該可以轉(zhuǎn)換；而float->long long呢？貌似應(yīng)該不認(rèn)為可轉(zhuǎn)換吧

嗯，支持左閉右開區(qū)間

頂空老師~！

@空明流轉(zhuǎn)
我現(xiàn)在倒是有了個不太完美的解法：

// 判斷 T 到 U 的轉(zhuǎn)換是否存在
template <typename T, typename U>
class Conversion
{
private:
typedef char Small;
class Big { char XXX[2]; };
static Small Test(U);
static Big Test(...);
static T MakeT();
public:
enum
{
Exists = (sizeof(Test(MakeT())) == sizeof(Small)),
};
};

// 以上對內(nèi)置類型的判斷還是不夠給力，
// 比如給出 T = int，U = double，它認(rèn)為可轉(zhuǎn)換；反過來，它還是認(rèn)為可轉(zhuǎn)換，只是多了個 warning 而已。
// 所幸，這些內(nèi)置類型是有限的，我們可以采用人肉的方法，兩兩組合，分別給出偏特化版本。
// 簡潔起見，僅列出 int 和 double 兩個。
template <>
class Conversion<int, double>
{
public:
enum
{
Exists = true,
};
};

template <>
class Conversion<double, int>
{
public:
enum
{
Exists = false,
};
};


template <bool Condition, typename TypeIfTrue, typename TypeIfFalse>
struct Select
{
typedef TypeIfFalse Type;
};

template <typename TypeIfTrue, typename TypeIfFalse>
struct Select<true, TypeIfTrue, TypeIfFalse>
{
typedef TypeIfTrue Type;
};

struct NullType;

template <typename T, typename U>
struct CommonType
{
typedef typename Select<Conversion<T, U>::Exists,
U,
typename Select<Conversion<U, T>::Exists,
T,
NullType>::Type
>::Type Type;
};

template <typename T1, typename T2>
typename CommonType<T1, T2>::Type Min(T1 t1, T2 t2)
{
return (t1 < t2 ? t1 : t2);
}

int main()
{
int a = 0;
double b = 1;
CommonType<int, double>::Type m1 = Min(a, b);
CommonType<double, int>::Type m2 = Min(a, b);
int m3 = Min(a, b);
double m4 = Min(a, b);

return 0;
}


只是。。。太人肉了。。。

@周星星
不一定要 lambda 啊，單單一個普通函數(shù)就可以了，就像我原文里寫的那樣

@gbb21
這還沒到運(yùn)行時啊，模板函數(shù)特化的時候就知道了啊

@陳梓瀚(vczh)
比如 T1 = int, T2 = double，我期望返回類型是 double

@so
我不需要參數(shù)的數(shù)值大小，只需要知道類型信息啊，編譯期可以知道

@OwnWaterloo
你也認(rèn)為它多管閑事了？！好~哈哈！

可是現(xiàn)在，當(dāng)你訪問慢的時候，被墻的時候，你會覺得不僅僅被魚肉。。。

@coreBugZJ
仰慕會寫Win32游戲的

@volnet
看到這哥們的回復(fù)，我又看了下自己當(dāng)時的回復(fù)，一開始還真有點(diǎn)不知道當(dāng)時想表達(dá)什么。后來仔細(xì)看了下，應(yīng)該是這么個意思吧：你說 IsWOW64 不能用于檢測系統(tǒng)是32位還是64位的，原因是64位程序調(diào)用IsWOW64得到的結(jié)果不是預(yù)期的。我對這個因果推理的邏輯表示費(fèi)解。既然要檢測系統(tǒng)是32位還是64位的，程序本身必須是32位的，64位程序自然只能運(yùn)行在64位系統(tǒng)下不能運(yùn)行在32位系統(tǒng)下，所以對64位程序來說，是無所謂“檢測”操作系統(tǒng)是不是32位的。IsWOW64確實可以讓32位程序檢查到操作系統(tǒng)到底是32位還是64位，已經(jīng)充分地支持了“IsWOW64 可以用于檢測系統(tǒng)是32位還是64位的”。。。。好繞，不知道我表達(dá)清楚了沒有。所以，能不能拿64位程序調(diào)用 IsWOW64 的結(jié)果說事。

@coreBugZJ
不貼了，偶得太弱智了，還是DOS版的

呃。。。好懷舊啊。。。搞得哥也想貼坦克

哈哈

@OwnWaterloo
http://topic.csdn.net/u/20110221/16/86608158-ac06-4a45-b3bb-7f53ba3008fc.html，好多自以為是的人吶，還有人說“去看chrome源碼吧”

@OwnWaterloo
又看了一些人對回調(diào)函數(shù)的理解，覺得你在這個問題上如此激烈的反應(yīng)是必要的，太多人認(rèn)為function之類的玩意兒就能解決回調(diào)函數(shù)少參數(shù)的問題了，甚至沒意識到這個問題是什么問題。。。

路過，學(xué)習(xí)~

@aquarius
謝謝鼓勵~！

@dayn9
不要裝，好嗎？有什么話說出來，大家都可以受教~

@C++愛好者
呵呵。重新回顧了上面這么多糾結(jié)的提法（塊啊、字節(jié)流啊、二進(jìn)制格式啊、struct啊，char啊），再看到你說明白話，頓感輕松。塊也好、二進(jìn)制格式也好、struct也好，不就是一堆字節(jié)么。。。

項目里只要是帶上業(yè)務(wù)邏輯處理的，就找不到高質(zhì)量的函數(shù)。。。。

@fixdot
為什么刪除了？

@fixdot
對，當(dāng)時也是這樣的問題。也是原因不明。可是既然原因不明，那么作為論據(jù)其實有問題的。如果這兩個函數(shù)確實有引用計數(shù)的，那么應(yīng)該提倡用時CoInitialize，用完馬上CoUninitialize。除非能夠說出“一個進(jìn)程里最好只調(diào)用一次”的道理。

@OwnWaterloo
如果好用我就用呀~

@OwnWaterloo
在足夠牛b的機(jī)器上，不見得新版本比舊版本慢啊

@Carnegieer
Email: kejinjin (at) gmail.com

@zdhsoft
謝謝推薦，抽空一定看看

要是大一能看到有這樣高度的解釋就好了，可惜那些教授們根本不去鉆研教學(xué)方法，不知道怎么講大家才能理解，，，說不定他們自己也不一定理解，或者不一定理解自己是怎么理解的

@by
就算有這樣的需求，也應(yīng)該在另一個地方寫專用工具來處理源代碼或者處理二進(jìn)制文件，而不應(yīng)該在源代碼中丟下這些不三不四的東西讓別人費(fèi)解。寫這樣的代碼不就是為了炫耀一下“我懂機(jī)器碼”么？這沒什么值得炫耀的。

@by
體現(xiàn)的是折騰，不是功力，謝謝。
除非你是學(xué)院派的，不在工程前線呆。

話題不錯，例子不好，支持樓上

@foxriver
好的，謝謝分享，有空我得想辦法改進(jìn)下~

@abeng
@小龍紅
你們倆都有DirectUI傾向。。。就是因為不想要Windows來管理嗎？想了解下，Windows管理方式的那些方面值得我們拋棄它？

@欲三更
謝謝你的分享~
控件工作量確實很多啊，標(biāo)準(zhǔn)的，自己的，才做了一個半~突然又有點(diǎn)不想解析 WPARAM LPARAM 了。。。

@foxriver
謝謝告知！

他的書沒看過，僅僅看了上面有人貼出的網(wǎng)址。雖說看上去態(tài)度不錯，但是有些詞語偏偏不用大家約定俗成的，自搞一套，這樣不好，，除非他真的能創(chuàng)造出一個流派。

@陳梓瀚(vczh)
@OwnWaterloo
一直用 Window Live Writer 寫~

@空明流轉(zhuǎn)
絕不太監(jiān)！

@陳昱(CY)
嗯！謝謝支持~！

@廷
咱換個位置多好，呵呵。說不定我也喜歡數(shù)學(xué)的，只是在讀數(shù)學(xué)的時候很不喜歡。

@gbb21
我沒有認(rèn)識的在校的學(xué)妹了，進(jìn)不了校上不了98了，求vpn~！

@OwnWaterloo
像是……帶版本控制的wiki？

@kongque
好上司難求，一個正常上司就夠了