1、打包人員不該偷懶,他們應(yīng)該知道完整的精確的文件清單,而不僅僅是“某個(gè)目錄下的所有文件”
2、還是沒有看出來(lái)把solution單獨(dú)藏在一個(gè)目錄的用意。
個(gè)人非常討厭什么 bin,source,solution,。。。
你要么就純粹自己搞,bin、source 都可以,就別 solution、project 了,最后自己寫腳本
要么就用 solution、project,目錄就大體上按默認(rèn)的,一個(gè)project一個(gè)目錄,
既用 solution、project,又獨(dú)立搞一套目錄體系,然后修改一大堆純粹關(guān)于目錄的配置參數(shù),何必呢
僅僅以快或慢來(lái)決定用哪個(gè)我覺得不好
這兩個(gè)函數(shù)的語(yǔ)義是不同的,要看上下文中你要操作的究竟是字符串還是普通內(nèi)存。就算沒法區(qū)分這一點(diǎn),快慢也并非唯一標(biāo)準(zhǔn),可能還有一些因素是重要的。
(抱歉,最近有點(diǎn)排斥“唯性能主義”。)
re: 失足于shared_ptr 溪流 2011-04-02 09:53
返回的不是臨時(shí)對(duì)象的引用。
之所以 warining,是因?yàn)?m_pB 會(huì)隨著 C 對(duì)象的析構(gòu)而消亡,此時(shí),之前有這個(gè)返回的引用就成了孤魂野鬼了。m_pB 在類外的地位就是一個(gè)局部變量。
@flyinghearts
是的,應(yīng)該顯式轉(zhuǎn)換,但是我必須知道原始返回類型后,才能考慮如何轉(zhuǎn)換得到的結(jié)果。當(dāng)我寫下min(1LL, 2.0f) 的時(shí)候,我該認(rèn)為返回類型是什么呢?或者是你假定不允許寫下min(1LL, 2.0f)?請(qǐng)注意,當(dāng)寫下“min(1LL, 2.0f)”的時(shí)候,我并不了解min內(nèi)部做了什么,我只是認(rèn)為在比較他們的大小,不會(huì)猜到min里面會(huì)進(jìn)行類型轉(zhuǎn)換,因此不會(huì)寫成“min((float)1LL, 2.0f)”或者“min(1LL, (long long)2.0f)”。
對(duì)內(nèi)建類型來(lái)說(shuō),sizeof 誰(shuí)大就轉(zhuǎn)到誰(shuí),也不是最合理的
比如int->double,我認(rèn)為應(yīng)該可以轉(zhuǎn)換;而float->long long呢?貌似應(yīng)該不認(rèn)為可轉(zhuǎn)換吧
@空明流轉(zhuǎn)
我現(xiàn)在倒是有了個(gè)不太完美的解法:
// 判斷 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)),
};
};
// 以上對(duì)內(nèi)置類型的判斷還是不夠給力,
// 比如給出 T = int,U = double,它認(rèn)為可轉(zhuǎn)換;反過(guò)來(lái),它還是認(rèn)為可轉(zhuǎn)換,只是多了個(gè) warning 而已。
// 所幸,這些內(nèi)置類型是有限的,我們可以采用人肉的方法,兩兩組合,分別給出偏特化版本。
// 簡(jiǎn)潔起見,僅列出 int 和 double 兩個(gè)。
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 啊,單單一個(gè)普通函數(shù)就可以了,就像我原文里寫的那樣
@gbb21
這還沒到運(yùn)行時(shí)啊,模板函數(shù)特化的時(shí)候就知道了啊
@陳梓瀚(vczh)
比如 T1 = int, T2 = double,我期望返回類型是 double
@so
我不需要參數(shù)的數(shù)值大小,只需要知道類型信息啊,編譯期可以知道
@OwnWaterloo
你也認(rèn)為它多管閑事了?!好~哈哈!
re: 徹底放棄CN域名 溪流 2011-03-28 09:19
可是現(xiàn)在,當(dāng)你訪問(wèn)慢的時(shí)候,被墻的時(shí)候,你會(huì)覺得不僅僅被魚肉。。。
@coreBugZJ
仰慕會(huì)寫Win32游戲的
@volnet
看到這哥們的回復(fù),我又看了下自己當(dāng)時(shí)的回復(fù),一開始還真有點(diǎn)不知道當(dāng)時(shí)想表達(dá)什么。后來(lái)仔細(xì)看了下,應(yīng)該是這么個(gè)意思吧:你說(shuō) IsWOW64 不能用于檢測(cè)系統(tǒng)是32位還是64位的,原因是64位程序調(diào)用IsWOW64得到的結(jié)果不是預(yù)期的。我對(duì)這個(gè)因果推理的邏輯表示費(fèi)解。既然要檢測(cè)系統(tǒng)是32位還是64位的,程序本身必須是32位的,64位程序自然只能運(yùn)行在64位系統(tǒng)下不能運(yùn)行在32位系統(tǒng)下,所以對(duì)64位程序來(lái)說(shuō),是無(wú)所謂“檢測(cè)”操作系統(tǒng)是不是32位的。IsWOW64確實(shí)可以讓32位程序檢查到操作系統(tǒng)到底是32位還是64位,已經(jīng)充分地支持了“IsWOW64 可以用于檢測(cè)系統(tǒng)是32位還是64位的”。。。。好繞,不知道我表達(dá)清楚了沒有。所以,能不能拿64位程序調(diào)用 IsWOW64 的結(jié)果說(shuō)事。
@coreBugZJ
不貼了,偶得太弱智了,還是DOS版的
@OwnWaterloo
又看了一些人對(duì)回調(diào)函數(shù)的理解,覺得你在這個(gè)問(wèn)題上如此激烈的反應(yīng)是必要的,太多人認(rèn)為function之類的玩意兒就能解決回調(diào)函數(shù)少參數(shù)的問(wèn)題了,甚至沒意識(shí)到這個(gè)問(wèn)題是什么問(wèn)題。。。
@dayn9
不要裝,好嗎?有什么話說(shuō)出來(lái),大家都可以受教~
@C++愛好者
呵呵。重新回顧了上面這么多糾結(jié)的提法(塊啊、字節(jié)流啊、二進(jìn)制格式啊、struct啊,char啊),再看到你說(shuō)明白話,頓感輕松。塊也好、二進(jìn)制格式也好、struct也好,不就是一堆字節(jié)么。。。
項(xiàng)目里只要是帶上業(yè)務(wù)邏輯處理的,就找不到高質(zhì)量的函數(shù)。。。。
@fixdot
對(duì),當(dāng)時(shí)也是這樣的問(wèn)題。也是原因不明。可是既然原因不明,那么作為論據(jù)其實(shí)有問(wèn)題的。如果這兩個(gè)函數(shù)確實(shí)有引用計(jì)數(shù)的,那么應(yīng)該提倡用時(shí)CoInitialize,用完馬上CoUninitialize。除非能夠說(shuō)出“一個(gè)進(jìn)程里最好只調(diào)用一次”的道理。
@OwnWaterloo
在足夠牛b的機(jī)器上,不見得新版本比舊版本慢啊
@Carnegieer
Email: kejinjin (at) gmail.com
re: 也談?wù)凣UI框架 溪流 2011-02-28 23:10
@zdhsoft
謝謝推薦,抽空一定看看
re: 孟巖blog理解矩陣一、二, 三 溪流 2011-02-22 20:30
要是大一能看到有這樣高度的解釋就好了,可惜那些教授們根本不去鉆研教學(xué)方法,不知道怎么講大家才能理解,,,說(shuō)不定他們自己也不一定理解,或者不一定理解自己是怎么理解的
re: 有時(shí),你真的太自信了 溪流 2011-02-22 16:49
@by
就算有這樣的需求,也應(yīng)該在另一個(gè)地方寫專用工具來(lái)處理源代碼或者處理二進(jìn)制文件,而不應(yīng)該在源代碼中丟下這些不三不四的東西讓別人費(fèi)解。寫這樣的代碼不就是為了炫耀一下“我懂機(jī)器碼”么?這沒什么值得炫耀的。
re: 有時(shí),你真的太自信了 溪流 2011-02-22 13:09
@by
體現(xiàn)的是折騰,不是功力,謝謝。
除非你是學(xué)院派的,不在工程前線呆。
re: 有時(shí),你真的太自信了 溪流 2011-02-21 12:45
話題不錯(cuò),例子不好,支持樓上
@foxriver
好的,謝謝分享,有空我得想辦法改進(jìn)下~
re: 也談?wù)凣UI框架 溪流 2011-02-16 00:40
@abeng
@小龍紅
你們倆都有DirectUI傾向。。。就是因?yàn)椴幌胍猈indows來(lái)管理嗎?想了解下,Windows管理方式的那些方面值得我們拋棄它?
re: 也談?wù)凣UI框架 溪流 2011-02-16 00:38
@欲三更
謝謝你的分享~
控件工作量確實(shí)很多啊,標(biāo)準(zhǔn)的,自己的,才做了一個(gè)半~突然又有點(diǎn)不想解析 WPARAM LPARAM 了。。。
re: 再次批判 裘宗燕 溪流 2011-01-31 13:31
他的書沒看過(guò),僅僅看了上面有人貼出的網(wǎng)址。雖說(shuō)看上去態(tài)度不錯(cuò),但是有些詞語(yǔ)偏偏不用大家約定俗成的,自搞一套,這樣不好,,除非他真的能創(chuàng)造出一個(gè)流派。
@陳梓瀚(vczh)
@OwnWaterloo
一直用 Window Live Writer 寫~
@廷
咱換個(gè)位置多好,呵呵。說(shuō)不定我也喜歡數(shù)學(xué)的,只是在讀數(shù)學(xué)的時(shí)候很不喜歡。
@gbb21
我沒有認(rèn)識(shí)的在校的學(xué)妹了,進(jìn)不了校上不了98了,求vpn~!
@OwnWaterloo
像是……帶版本控制的wiki?
@kongque
好上司難求,一個(gè)正常上司就夠了