|
|
re: 談目前項目組的代碼提交制度 那誰 2010-07-09 21:43
@陳梓瀚(vczh)
話說我已經(jīng)開始覺得搭建這個一個系統(tǒng)也是一個有利于他人的事情了....
re: C++的流設(shè)計很糟糕 那誰 2010-07-09 20:50
@Noock
我文章的目的,是要說明C++的這種機(jī)制存在缺陷,已經(jīng)強(qiáng)調(diào)了很多次.你可以"規(guī)避"這個問題,不能否認(rèn)我的結(jié)論.
re: 談目前項目組的代碼提交制度 那誰 2010-07-09 18:54
@Sparkle
是的,這樣做才能嚴(yán)格控制checkin代碼的質(zhì)量,不可能隨便改幾行代碼,也不說明改了什么,就讓你提交到代碼庫中的.
re: C++的流設(shè)計很糟糕 那誰 2010-07-09 18:52
@Noock 是的,我測試了一下,確實不行.查了一些文檔,發(fā)現(xiàn)是因為C語言里面認(rèn)為,以%u輸出char是正確的,比如這里: http://blog.csdn.net/wangyadong/archive/2009/05/22/4208013.aspx我把代碼貼在這里: #include <stdarg.h> extern void my_printf(const char *format,...) __attribute__((format(printf,1,2))); #define printf my_printf int main() { char cc = -1; printf("cc=%u\n", cc); return 0; } void my_printf(const char *format,...) { // do the really fuck output } 使用宏替代掉系統(tǒng)的printf的作用是,用戶可以完全不知道后面的改動,照常使用printf的功能.而你的LOG宏,只是規(guī)避了問題,沒有解決我提出的log<<"hello"<<"world"無法判斷結(jié)束符的問題,如果你有一種辦法,可以不改變我用戶的輸入,而解決這個問題并且不帶來新的問題,這個才算是解決吧.
re: C++的流設(shè)計很糟糕 那誰 2010-07-09 13:47
@Noock 請看這里: http://blog.chinaunix.net/u3/91522/showart_2054004.html我的做法會在項目組內(nèi)禁止直接使用printf,而使用加上了__attribute__封裝的函數(shù). 緊跟著的問題是,如何能保證禁止直接使用printf呢,define宏解決.
re: C++的流設(shè)計很糟糕 那誰 2010-07-09 10:34
@Noock
"解決"問題應(yīng)該是"自封閉"的,也就是不引入別的問題.在這里我提出的類sprintf的解決方式,帶來的格式輸入有誤,緩沖區(qū)溢出等問題,我都有方法解決掉,這才叫"解決"問題.
你的第一種方式,帶來的另外一個問題,你沒有幫我"解決"掉,所以,你這不叫"解決"問題.
斗膽說一句,平時工作中,你都是這么給人"解決"問題的么?假設(shè)你是制造車的,我要解決代步問題,從你那里買輛車,如果還要擔(dān)心剎車會失靈,這個能叫做"解決"問題么?
你的另一種方式,不是"解決"問題,相反,恰恰如我說的那樣,是這種方式存在缺陷,你才要使用別的方式規(guī)避它,這也就反證了這個方式是存在缺陷的了.
你說到編譯器不能解決所有的問題,我承認(rèn),但是要最大限度讓編譯器發(fā)揮作用來幫助解決問題,人的因素很不穩(wěn)定,不能把項目的成敗過多的放在這些不穩(wěn)定因素中.
re: C++的流設(shè)計很糟糕 那誰 2010-07-09 00:47
說白了,你提供了這個機(jī)制,又不提供相應(yīng)的檢查機(jī)制,如何叫"解決"?
re: C++的流設(shè)計很糟糕 那誰 2010-07-09 00:45
@Noock
我上面已經(jīng)回復(fù)了,你那個辦法怎么叫解決?不是又引入了新的問題么?
"請問你如何從語法,編譯器的角度避免用戶沒有輸入最后那個end呢?"
你的另一種做法,不是解決,叫規(guī)避,謝謝.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 23:41
@Noock
行了,到此打住吧,我只想證明這個東西是確實有缺陷的.到此為止.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 23:27
@Noock
sprintf可以使用編譯器的特性進(jìn)行檢查,gcc就可以做到.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 23:21
我在上面已經(jīng)就這個方式進(jìn)行了回復(fù),恕我不再回復(fù).
再說一句,給他人定性下結(jié)論之前,自己先看清楚問題,和別人的回復(fù),同時自己去驗證過可行性,謝謝.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 23:19
@Noock
請問你如何從語法,編譯器的角度避免用戶沒有輸入最后那個end呢?
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 23:14
@Noock
你這個辦法上面已經(jīng)有人說過了.請看我的回復(fù),謝謝.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 22:36
@陳煜
另外,這個問題跟flush沒有一毛錢的關(guān)系,你這么問說明你對我提出的問題還是不了解,呵呵.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 22:04
@陳煜
行了,我證明了你說的辦法不能解決我這里提的問題.就這樣吧.
給他人下結(jié)論之前,麻煩你做過充分的驗證,我在上面可是有給出可編譯運行的程序的,謝謝.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 21:55
@陳煜
呵呵,我把那個codeproject的代碼拉下來編譯驗證,正是我上面給出來的結(jié)論.麻煩你自己回頭看看那份代碼和我文章中的描述吧.
以那個項目的代碼為例,在類basic_debugbuf的析構(gòu)中調(diào)用了sync,這個函數(shù)中再調(diào)用output_debug_string輸出字符.就是我文章中提到的情況:因為C++的流輸出對輸入?yún)?shù)的結(jié)束位置無法判斷,只能在析構(gòu)函數(shù)中做真正的輸出.
另外那篇文章,太長了,我不去看了.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 18:11
@陳煜
那請您給出可運行的代碼例子并且解決我上面的問題,謝謝.
re: 談目前項目組的代碼提交制度 那誰 2010-07-08 13:49
@sdww
提交到reviewboard,另一方面是為了讓你做的改動是有白紙黑字可查的,如果只是口頭上的說明,起不到這個效果,類似于工作中重要的事情需要發(fā)郵件確認(rèn).當(dāng)然,這里也并沒有排斥口頭上的交流啊.
re: C++的流設(shè)計很糟糕 那誰 2010-07-08 13:08
@Noock
那請您就事論事說一說怎么解決我提的問題,謝謝.
re: 談目前項目組的代碼提交制度 那誰 2010-07-08 12:54
@陳梓瀚(vczh)
我是這么看的,因為linux下面并沒有完整的這樣一套系統(tǒng),所以我們自己整合這些軟件搭建這個系統(tǒng)的工作,類比于微軟開發(fā)那套軟件的工作.
而不是搭建這個系統(tǒng)的工作,類比于使用微軟這套軟件搭建系統(tǒng)的工作.
哦 我自己說的都拗口,但愿表達(dá)清楚意思了.
re: 談目前項目組的代碼提交制度 那誰 2010-07-08 11:55
@陳梓瀚(vczh)
另外,我們寫的是服務(wù)器端的程序,必然不是跑在windows平臺的,微軟那套東西用不上.
re: 談目前項目組的代碼提交制度 那誰 2010-07-08 11:46
@陳梓瀚(vczh)
呵呵,請問你微軟做好那個軟件花了多少人力/時間呢?是不是說,你寫一個軟件完成要求的功能只花費了幾秒,工作量就可以定為只有幾秒呢?
re: 談目前項目組的代碼提交制度 那誰 2010-07-08 10:18
@cui
沒懂你的意思?我是說把這些軟件整合在一起搭建整個流程花了這么多時間.
呵呵,那個帖子里面的意思不是為了說operator<<復(fù)雜,我那篇文章主要強(qiáng)調(diào)的是C++流輸出對輸入?yún)?shù)結(jié)束判斷手段的缺失.那句"天哪"開頭的抱怨,是指編譯器在后面做了很多事情,要全部都了解到,代價太大.
re: C++的流設(shè)計很糟糕 那誰 2010-07-07 11:48
@陳梓瀚(vczh)
也有用模板,用模板創(chuàng)建callback,但是我不了解做法,只了解怎么使用,模板讓我很崩潰,一直不想深究.
re: C++的流設(shè)計很糟糕 那誰 2010-07-07 11:47
@陳梓瀚(vczh)
"其實每一個細(xì)節(jié)都規(guī)定的十分清晰"
我還真沒有覺得,也許是真的,但是要做到使用者也非常清晰,代價很大.就學(xué)一門語言的代價而言,我覺得過大,因為語言不是全部,還有很多需要學(xué)的,如果過分多的把精力放在語言學(xué)習(xí)上,我覺得有點本末倒置.所以,我現(xiàn)在只使用那些我清楚的,有把握的C++特性,你可以說我保守,但是我不是學(xué)生,沒多少時間花在語言學(xué)習(xí)上.
re: C++的流設(shè)計很糟糕 那誰 2010-07-07 11:24
@陳梓瀚(vczh)
呵呵,不知道你有沒有寫過服務(wù)器端程序,多線程同時寫log是肯定會存在的.
至于說的sprintf有緩沖區(qū)溢出問題,也可以有做法進(jìn)行避免.
總之,我的結(jié)論是C++的流在判斷輸入結(jié)束方面存在缺陷,至于后面跟的帖子寫的其他格式,則不是我關(guān)注的重點了,我這篇文章只為了說明C++的這個缺陷,這是我寫這篇文章的目的.
另外,你那個微積分和幾何的比喻放在這里不妥,兩者不能解決相同的問題,不屬于一個類型.
re: C++的流設(shè)計很糟糕 那誰 2010-07-06 22:35
to cui and cppexplore
我們看的不是一個地方,呵呵.
re: C++的流設(shè)計很糟糕 那誰 2010-07-06 22:26
@陳梓瀚(vczh)
另外,還有個問題,很難在編譯語法層面保證你的最后一個輸入是那個標(biāo)記類吧....
re: C++的流設(shè)計很糟糕 那誰 2010-07-06 14:11
@陳梓瀚(vczh)
我想了想 你這樣還是有問題的,比如一次輸入幾個參數(shù) 將會在幾次函數(shù)調(diào)用中完成 如果我需要做到是多線程的 這一點如何保證呢?還是類sprintf那樣的在一個函數(shù)中搞定所有的事情吧.
re: C++的流設(shè)計很糟糕 那誰 2010-07-06 14:03
@陳梓瀚(vczh)
C++的設(shè)計里面 編譯器做了太多額外的事情 以至于你要用好這么語言不得不去多了解細(xì)節(jié) 我覺得這是很糟糕的地方 因為你需要付出很大的代價才能對這門語言有足夠的了解.
re: C++的流設(shè)計很糟糕 那誰 2010-07-06 13:55
@陳梓瀚(vczh)
嗯,你說的那種方式 確實也是個辦法吧.
@Kenny Yuan
哦,怎么說?談?wù)勀愕睦斫?
@Kenny Yuan
我的意思是編譯器生成的構(gòu)造函數(shù)不知道會給類成員對象賦什么初值.如果自己寫的話,給它們賦一個明確的初值,這樣在出問題的時候一看,知道這些都是沒有被初始化過的.
@OwnWaterloo
異常少量使用過,已經(jīng)基本不用,觀點已經(jīng)在前面闡述過.如果一個特性,我認(rèn)為會給我?guī)砝_,同時目前所掌握的,已經(jīng)可以滿足我的需求,為什么我還要花時間去多學(xué)呢.有時候選擇過多,反而會帶來困擾吧.這個是我的觀點,無意強(qiáng)加于誰身上.同時,他人也無需強(qiáng)加于我身上.
"另外， 這種高壓政策下的google的代碼我沒看過， 所以無法評論其質(zhì)量高低。
但肯定是"原始且不美觀"的。"
這句話里面的語調(diào),我個人認(rèn)為過于狂妄了,呵呵.
如果你不能心平氣和的討論問題,而使用一些自己臆斷的詞匯去描述,比如"原始切不美觀","質(zhì)量怎么可能高",我個人認(rèn)為繼續(xù)下去的意義不大.
@OwnWaterloo
我反對你以偏概全將使用異常的態(tài)度推及到指針使用,這不是具體問題具體分析的態(tài)度.
其次,你的語氣有些過于狂妄了.就結(jié)果而言,google出品的這些軟件,雖然大部分都看不到代碼,從使用的角度看,質(zhì)量是有目共睹的,反之看它們的一些規(guī)定做法,有可取之處,而不是像你所言的"質(zhì)量怎么可能高".
我還是堅持我的看法,異常的使用導(dǎo)致了程序的走向難以從代碼中一目了然的看出來,給問題定位帶來困難.
@OwnWaterloo 另外,我見到的google開源出來的python代碼不多,java我不會,就更沒看過了,但是這份python代碼: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py里面似乎就沒有使用到異常.
@OwnWaterloo
那你能對規(guī)范中描述的異常的缺陷進(jìn)行回復(fù)么?我里面提到的,由于引入了異常,導(dǎo)致代碼走向難以預(yù)測,這一點如何解決?類似unix API那樣的,根據(jù)返回值判斷是否成功,根據(jù)errno判斷失敗原因,是非常簡潔明了的做法,我更傾向于設(shè)計出這樣的API.
@OwnWaterloo
又學(xué)了一個成語"因噎廢食 ( yīn yē fèi shí )":原意是說，因為有人吃飯噎住了，索性連飯也不吃了，這太荒謬了。比喻要做的事情由于出了點小毛病或怕出問題就索性不去干
能解釋一下在這里針對這個帖子做這個回復(fù)的含義么?
@ping
你說的沒錯,之前這個問題一直沒有發(fā)現(xiàn),是因為我之前寫的服務(wù)器程序都是父子進(jìn)程的模式,能否給我留一個聯(lián)系方式,我將在下一次修正這個BUG的時候在changelog中加入你的信息,謝謝.你可以在私人留言中給我留下聯(lián)系方式.
@ping
1.第一點我沒太看明白,我的測試用例就是使用多進(jìn)程去進(jìn)行壓力測試的,好像還沒有發(fā)現(xiàn)問題.
2.這一點我也比較頭疼,但是目前沒有找到降低鎖粒度的辦法.find操作要加寫鎖,是因為根據(jù)LRU算法,每次訪問過的節(jié)點,需要往鏈表頭走一步,所以也有更新的操作.這樣,經(jīng)常被find的元素,就會越靠近鏈表頭.
3.是的,這個算法類似STL中內(nèi)存池的設(shè)計.
re: 方法與工具 那誰 2010-04-15 18:10
@陳梓瀚(vczh)
如你這樣目標(biāo)明確的使用工具,倒是很好,我不是反對使用工具,只是覺得不應(yīng)該本末倒置,方法比工具重要.
re: 方法與工具 那誰 2010-04-15 12:54
@helloworld
呵呵,沒有說不用吧,這里的意思只是強(qiáng)調(diào)方法比工具更重要些.
概念性的錯誤:mapreduce不是分布式文件系統(tǒng),你說的應(yīng)該是GFS.
@阿福
當(dāng)當(dāng)前freepool超過一定數(shù)量時，會進(jìn)行merge操作進(jìn)行整理。
按位置排序是為了merge合并方便。
按尺寸排序是為了根據(jù)所要求的尺寸進(jìn)行二分查找方便。
這兩點前面一節(jié)都有提到。
@guest
因為tc相對而言較簡單,對我入門閱讀數(shù)據(jù)庫實現(xiàn)比較方便
@helloword
推薦你去看看stevens的unix網(wǎng)絡(luò)編程。
|