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