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