• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            可冰

            冰,是沉睡著的水......

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              37 隨筆 :: 5 文章 :: 94 評論 :: 0 Trackbacks

            2006年7月13日 #

            我已在百度空間新建博客,歡迎大家來訪。
            posted @ 2006-07-13 15:17 可冰 閱讀(1139) | 評論 (15)編輯 收藏

            2006年6月27日 #

            http://post.baidu.com/f?kz=109415855
            posted @ 2006-06-27 22:14 可冰 閱讀(395) | 評論 (0)編輯 收藏

            2006年6月23日 #

            Apache中如何配置才能使所有請求都由某一個頁面處理。即:
            在http://some.thing.com/下有一個處理器,叫handler.xxx,那么類似下面的

            URL請求,都由此處理器接收并處理。
            http://some.thing.com/handler/other/string/etc
            也即上面的相當(dāng)于
            http://some.thing.com/handler.xxx?other/string/etc


            posted @ 2006-06-23 19:41 可冰 閱讀(473) | 評論 (0)編輯 收藏

            網(wǎng)絡(luò)的并發(fā)連接數(shù)到底是由什么限制的?即哪些因素是最主要的,難道不能解決嗎?
            現(xiàn)在一個好的網(wǎng)絡(luò)程序,通常最多能達到多少的并發(fā)連接數(shù)?

            posted @ 2006-06-23 19:40 可冰 閱讀(600) | 評論 (2)編輯 收藏

            2006年4月21日 #


            ??? ??? 在C/C++中,變量及函數(shù)的定義一般都是在.h/.hpp文件中說明原型,而在對應(yīng)的.c/.cpp文件中來進行實現(xiàn).
            ??? ??? 這種情況下,頭文件最終是給用戶使用的,以便讓用戶了解有哪些接口可以使用;而.c/.cpp文件是開發(fā)者使用的,以便讓其它開發(fā)人員了解它的實現(xiàn)邏輯.因此這兩個文件中肯定都是需要詳細的注釋的.在.h/.hpp文件中,主要說明函數(shù)的使用方法,如參數(shù)的意義,返回值的定義等.而.c/.cpp文件中,主要說明函數(shù)的實現(xiàn)邏輯等.

            ??? ??? 不知道上面的做法是否合適.請大家指正!
            ??? ??? 另外,大家在實際編程過程中是如何做的?

            ??? ??? 事實上,我自己在實踐過程中卻總是偏向于把注釋寫到一個地方,或者注釋原型,或者注釋實現(xiàn)(前者比較多),甚至干脆兩邊都寫一樣的(但這樣的話內(nèi)容經(jīng)常會不一樣).這樣的方法讓我在編程過程中吃盡了苦頭哇.

            posted @ 2006-04-21 15:20 可冰 閱讀(1119) | 評論 (3)編輯 收藏

            2005年11月28日 #

            前幾天看了榮耀老師對Bjarne先生的訪談,其中Bjarne說的一句話我印象特別深刻:

            榮耀:一個有點兒八卦的問題。C++標準委員會中有中國人嗎?有中國人向C++標準委員會遞交過提案嗎? 

            Bjarne我想不起來最近的提案和中國人有關(guān)。委員會中有一個IBM的新代表,姓王。我猜他是中國人,但我還不認識他。 

            考慮到中國有那么多人在從事計算機工作,一直很奇怪為什么看不到你們對C++0x標準化工作的參與。

            我不知道這究竟是怎么回事。

            自從我前段時間訂閱了Google新聞組中的comp.lang.c、c++論壇,我看到的所有帖子幾乎都是在討論C++0x標準的。給我的感覺就像這里面都是標準委員會的成員或那一類的高手,我也沒有參與過任何討論,甚至也沒細心去看看相關(guān)的問題。我也很關(guān)注C++0x標準的制定,但卻從來沒有參與進去或想過要參與進去,這又是為什么呢?

            我想大多數(shù)的朋友也可能是這樣的情況吧。并不是不想?yún)⑴c,而是從來沒有想到過。我想這一定和我們的教育有關(guān)。我們被培養(yǎng)為只接受而不用去參與,我們只去被動的學(xué)習(xí)新的知識,而從沒有想過去主動的參與到新知識的產(chǎn)生的過程中。

            不過,現(xiàn)在情況應(yīng)該改變一下了,至少我們已經(jīng)看到Bjarne先生的提醒了:我們要參與進去!不僅僅是參與C++0x的標準制定的問題,而是思想習(xí)慣的問題。

            朋友們,我們要改變現(xiàn)在的這種思維方式了,要參與到更多的活動中去。

            posted @ 2005-11-28 13:51 可冰 閱讀(811) | 評論 (5)編輯 收藏

            2005年11月22日 #

            //自己翻譯的,本想整理一下,但一直沒時間,現(xiàn)在就這樣放上來吧,有錯就批,別客氣,呵呵。

            C++編碼規(guī)范

            一、組織與策略問題

            If builders built buildings the way programmers wrote programs, then the
            first woodpecker that came along would destroy civilization.
            ----Gerald Weinberg
            在C和C++的主要傳統(tǒng)中,我們認為是一種零基礎(chǔ)的習(xí)慣.第0條是一個根本的指示,它涵蓋了編碼規(guī)范中我們認為是最基本的建議.
            在這介紹性的一節(jié)的其余部分中,我們精心選取了其中的少量問題加以闡述,這些大多與編碼本身無直接關(guān)系,但卻是寫出可靠代碼的基本工具和技術(shù).
            在這一節(jié)中我們認為最有價值的是第0條不要因小失大.(或:知道什么不需要規(guī)范化.)

            0. 不要因小失大. (或:知道什么不需要規(guī)范化.)

            摘要

            僅說必要的話:不要堅持個人品味或陳舊的習(xí)慣.

            討論

            真只是個人品味且不影響正確性或可讀性的結(jié)論不屬于編碼標準.任何專業(yè)程序員可以很容易地讀寫稍微不同于他所習(xí)慣的格式的代碼.
            在每個源文件甚至每個工程中都要用一致的格式,因為在幾種不同編碼風(fēng)格的代碼片段中跳轉(zhuǎn)是很不協(xié)調(diào)的.但是不要企圖在不同項目或公司中堅持一致地格式.
            下面是幾條通用的結(jié)論,這里重要的不是去制定規(guī)則,而只是要保持與你維護的文件的風(fēng)格的一致:
            不必明確指定要縮進多少,但要縮進以突出結(jié)構(gòu):用你喜歡的任意數(shù)量的空格縮進,但至少要在同一文件中保持一致.
            不必強行保持特定的行長度,但要保持行具有可讀性:用你喜歡的任意長度的行長,但不要太長了.研究表明十個單詞以內(nèi)的寬度對眼睛跟蹤是最理想的.
            不要過度制定命名規(guī)則,但要用一致的命名約定:僅有兩點必須要做的:a)決不用"隱秘的"名稱,也即以一個下劃線開頭或包括雙下劃線的名稱;以及b)總是用字母全部大寫的單詞命名宏并且決不要考慮定義一個常用或縮寫單詞的宏(包括常用模板參數(shù),比如T和U;以#define T anything定義任何東西是極其不好的做法).此外,要用一致的有意義的名稱,并按照文件或模塊的約定.(若你不能決定你自己的命名約定,試試這種方式:以各單詞首字母大寫方式命名類、函數(shù)和枚舉(LikeThis);命名變量時在前者基礎(chǔ)上小寫第一個單詞的首字母(likeThis);命名私有成員變量時在前者方式之后再加一個下劃線(linkThis_);以全大寫并用一個下劃線連接各單詞的方式命名宏(LINK_THIS).)
            不要規(guī)定注釋的風(fēng)格(除非有工具解析特定格式的注釋生成文檔),但要寫有用的注釋:如果可以的話以代碼來代替注釋(見第16條).不要在注釋中重復(fù)代碼;它們不能被同步維護.要寫解釋方法和基本原理的啟發(fā)性的注釋.
            最后,不要試圖堅持陳舊的規(guī)則(見例3例4),即使它們曾在舊編碼規(guī)范出現(xiàn)過.

            例子

          1. 例1:括號的放置.下面的幾種沒有任何可讀性上的差異.
            void using_k_and_r_style() {
            // K&R風(fēng)格
            }

            void putting_each_brace_on_its_own_line()
            {
            // 括號獨占一行
            }

            void or_putting_each_brace_on_its_own_line_indented()
            {
            // 括號獨占一行并縮進
            }
            任何專業(yè)程序員都可以不費力地讀寫上面所列的任何一種風(fēng)格的代碼.但要保持一致性:不要隨意的或以晦澀的嵌套方式放置括號,試著去遵循各文件中已有的風(fēng)格.在本書中,我們的括號有意識的在排版的約束中以最好的可讀性的來放置.
          2. 例2: 空格與制表符.由于編輯器對制表符解釋的不同,它可能被誤用,或被理解成凸出,或無縮進,這種情況下一些團隊合理地選擇禁用制表符.其他同樣有名望的團隊則合理地允許制表符,而采用紀律來避免其潛在缺點.只要保持一致性:當(dāng)團隊成員維護其他人的代碼時,如果你允許使用制表符,確保不要以代碼清晰度和可讀性為代價(見第6條).如果你禁用制表符,允許編輯器在讀入源文件時將空格轉(zhuǎn)換成制表符,以便用戶可以在編輯器中使用制表符;但要確保寫回文件的時候?qū)⑺鼈冞€原為空格.
          3. 例3: 匈牙利命名法. 將類型信息合并到變量名稱中的命名方式為類型不安全的語言(尤其是C)帶來了一些混合的作用.但這種命名法在面向?qū)ο笳Z言中沒有好處(只有壞處),尤其在泛型編程中是根本不可能的.因此,不會有哪個C++編碼規(guī)范會要求用匈牙利命名法,C++編碼規(guī)范可能合理地將其排除在外.
          4. 例4: 單入口,單出口("SESE"). 歷史上,一些編碼規(guī)范要求每個函數(shù)有且僅有一個出口,也即一個返回語句.這樣的要求在支持異常與析構(gòu)函數(shù)的語言中是過時的,在這些語言中,函數(shù)通常都會有許多隱式的出口.取而代之的是,按照像第5條那樣直接提倡更簡短的函數(shù)的標準,這樣會很自然地具有更容易理解代碼和把握錯誤的特性.

            參考

            [BoostLRG] · [Brooks95] $12 · [Constantine95] $29 · [Keffer95] p. 1 ·
            [Kernighan99] $1.1, $1.3, $1.6-7 · [Lakos96] $1.4.1, $2.7 · [McConnell93]
            $9, $19 · [Stroustrup94] $4.2-3 · [Stroustrup00] $4.9.3, $6.4, $7.8, $C.1
            · [Sutter00] $6, $20 · [SuttHysl01]

            1. 以高警告級別干凈地編譯

            摘要

            將警告銘記于心:使用你的編譯器的最高警告級別.要求干凈(無警告)的構(gòu)建.理解全部的警告,并通過修改代碼消除警告,而不是通過降低警告級別.

            討論

            編譯器是你的好朋友.若它由于一個特定的結(jié)構(gòu)而發(fā)出一個警告,通常你的代碼含有潛在的問題.
            成功構(gòu)建應(yīng)該是干凈的(無警告的).如若不是這樣,你將會很快養(yǎng)成快速瀏覽輸出結(jié)果的習(xí)慣,進而你將錯過真正的問題.(見第2條)
            消除警告: a)理解它;然后b)更改你的代碼去消除警告并讓你想讓它所做的事情對人和編譯器都更清楚.
            一定要做這一步,即使一開始程序看起來正確運行了,或者即使你肯定警告是良性的.即使是良性警告也可以使后面的指出真正危險的警告變得隱晦.

            例子

          5. 例1: 第三方頭文件.你不可能去修改一個引起(或許是良性的)警告的庫頭文件.因此你要在你自己的頭文件中包含原始頭文件并僅在這個頭文件的作用域內(nèi)選擇性的屏蔽掉這些煩人的警告,然后在你其它的項目文件中包含你的這個包裝過的頭文件.例如(注意這里的警告控制語法在編譯器間是不同的):
            // 文件: myproj/my_lambda.h -- 包裝Boost的lambda.hpp
            // 總是使用這個文件,而不直接使用lambda.hpp.
            // 注意: 我們的構(gòu)建現(xiàn)在自動檢查: "grep lambda.hpp ".
            // Boost.Lambda產(chǎn)生我們所知道的無害的編譯警告.
            // 當(dāng)作者修正它時我們將移除下面的#pragma語句,但是這個頭文件仍將存在.
            //
            #pragma warning(push) // 僅屏蔽這個頭文件
            #pragma warning(disable:4512)
            #pragma warning(disable:4180)
            #include #pragma warning(pop) // 恢復(fù)原來的警告級別
          6. 例2: "未使用過的函數(shù)參數(shù)."檢查以確保你真的不打算用這個函數(shù)參數(shù)(例如:它可能是占位符以便將來擴展,或是你代碼中從未用到但卻是必需的標準化函數(shù)簽名的一部分).如若它不是必需的,只要刪除這個函數(shù)參數(shù)就行了:
            // … 不使用提示的用戶自定義分配器內(nèi)部 …

            // 警告: "unused parameter 'localityHint'"
            pointer allocate( size_type numObjects, const void *localityHint = 0 ) {
            return static_cast( mallocShared( numObjects * sizeof(T) ) );
            }

            // 新版本: 消除警告
            pointer allocate( size_type numObjects, const void * /* localityHint */ = 0 ) {
            return static_cast( mallocShared( numObjects * sizeof(T) ));
            }
          7. 例3: "變量定義了但卻從未使用."檢查確保你真的不想引用這個變量.(一個基于棧的RAII對象經(jīng)常引起這樣的不合理的警告,請見第13條.)如若它不是必需的,通常你可以插入一個變量自求值的表達式使編譯器安靜(這一求值不會對運行時速度有影響):
            // 警告: "變量'lock'定義了但卻從未使用."
            void Fun() {
            Lock lock;

            // …

            }

            // 新版本: 消除了警告
            void Fun() {
            Lock lock;
            lock;

            // …

            }
          8. 例4: "可能使用了未初始化的變量."那就初始化這個變量(見第19條).
          9. 例5: "丟失返回語句."即使你的控制流永遠也不可能到達函數(shù)的末尾,編譯器有時也會要求有一個返回語句(例如無限循環(huán)、異常拋出語句以及其它類型的返回語句).這也許是一件好事,因為有時你只是認為控制流不會運行到末尾.例如無default的switch語句沒有修改的彈性,因些要有一個default語句執(zhí)行assert( false ) (另見第6890條):
            // 警告: 丟失"return"
            int Fun( Color c ) {
            switch( c ) {
            case Red: return 2;
            case Green: return 0;
            case Blue:
            case Black: return 1;
            }
            }

            // 新版本: 消除警告
            int Fun( Color c ) {
            switch( c ) {
            case Red: return 2;
            case Green: return 0;
            case Blue:
            case Black: return 1;
            default: assert( !"should never get here!" ); // !"string"的值為false
            return -1;
            }
            }
          10. 例6: "有符號/無符號不匹配."有符號數(shù)與無符號數(shù)之間的比較與賦值通常不是必需的.改變參與比較的變量的類型以使?jié)M足類型匹配要求.最壞情況下,插入一個顯式轉(zhuǎn)換.(由于編譯器為你插入這樣的轉(zhuǎn)換,也會警告你它所做的,所以你最好不要讓它出現(xiàn).)

            例外

            有時編譯器可能發(fā)出一個厭煩的甚至欺騙性的警告(比如純粹的擾亂信息),但沒有可提供的方法去消除它,而且去修改代碼去消除它可能是不可實現(xiàn)的或是徒勞的工作.在這些罕見的情況下,作為一個團隊決策,除去這個只是無聊的警告的煩人的工作是:僅使特定警告無效,并盡可能是局部性的,并寫一個清晰的注釋文檔說明為什么這樣做是必要的.

            參考

            [Meyers97] $48 · [Stroustrup94] $2.6.2

            2. 使用自動構(gòu)建系統(tǒng)

            摘要

            按(單個)按鈕:使用一個無需用戶參與的全自動("一鍵觸發(fā)")構(gòu)建系統(tǒng).

            討論

            一個一鍵觸發(fā)式構(gòu)建方法是基本的.它必須進行可靠的和可重復(fù)的轉(zhuǎn)換,將你的源文件轉(zhuǎn)換為可交付的程序包.有很多自動構(gòu)建工具可以使用,沒有理由不去用它.挑選一個,使用它.
            我們已見過一些忽視了"一鍵觸發(fā)"式要求的組織.一些人認為隨處點幾下鼠標,就可以運行一些工具來注冊COM/CORBA服務(wù),或通過手工定制的一個合理構(gòu)建過程拷貝一些文件.但是你沒有時間和精力可以浪費在一些機器能做得更好更快的事情上.你需要一鍵觸發(fā)式的自動化的和可靠的構(gòu)建.
            成功的構(gòu)建應(yīng)該是沒有任何警告的(見第1條).理想化的構(gòu)建不產(chǎn)生擾亂信息,而僅是一個日志消息:"構(gòu)建成功完成."
            有兩個構(gòu)建模式:增量構(gòu)建和完全構(gòu)建.增量構(gòu)建僅重建自上自增量構(gòu)建或完全構(gòu)建以來被修改過的文件.推論:兩個連續(xù)的增量構(gòu)建中的后者應(yīng)該沒有任何輸出文件;如果有的話,你可能有一個依賴環(huán)(見第22條),或者你的構(gòu)建系統(tǒng)執(zhí)行了不必要的操作(例如生成不合理的臨時文件而只是丟棄它們).
            一個工程可以有不同形式的完全構(gòu)建.考慮用一系列本質(zhì)的特征確定你的構(gòu)建的參數(shù);很可能候選者就是目標式體系結(jié)構(gòu)、調(diào)試和發(fā)布、或更廣(基本文件和全部文件和完全安裝).一個構(gòu)建設(shè)置可以創(chuàng)建一個產(chǎn)品的基本的可執(zhí)行文件和庫,另一個可能也創(chuàng)建一些輔助文件,一個完全充實的構(gòu)建也可能創(chuàng)建一個包含你所有文件、可重發(fā)布的第三方庫和安裝代碼的安裝程序.
            隨著工程的進行,沒有自動構(gòu)建的花費也在增長.如果你一開始沒有用,你將浪費很多時間和資源.更糟糕的是,隨著自動構(gòu)建成為無法抵抗的需求,你將會有比項目一開始更多的壓力.
            大項目可能有一個"構(gòu)建師/主管",他的工作就是照料構(gòu)建系統(tǒng).

            參考

            [Brooks95] $13, $19 · [Dewhurst03] $1 · [GnuMake] · [Stroustrup00] $9.1

            3. 使用一個版本控制系統(tǒng)

            摘要

            好記性比不上爛筆頭:使用一個版本控制系統(tǒng)(VCS).決不要讓檢出的文件保留很長時間.一旦你的更新的單元通過測試就盡快檢入.確保檢入的代碼不會破壞整個構(gòu)建.

            討論

            幾乎所有不平凡的工程都需要一個以上的開發(fā)者和/或超過一周的工作量.在這樣的工程中,你將需要比較同一文件的歷史版本以確定變化是什么時候(和/或被誰)引入的.你也將需要控制和管理源代碼的變化.
            當(dāng)有多個開發(fā)者時,幾個開發(fā)者很可能會在同一時間對同一文件的不同部分進行并行地更改.你需要工具以自動進行文件的檢出和恢復(fù),以及在某些時候?qū)Σl(fā)編輯的合并.VCS自動操作和控制檢出,恢復(fù)以及合并.VCS比手工做的更快更準確.而且你不用花時間每天的去擺弄那些重復(fù)性的工作,你有軟件要寫.
            不要破壞構(gòu)建.在VCS中的代碼必須總是可以成功構(gòu)建的.
            存在很多的版本控制系統(tǒng)可供選擇,沒有理由不去用它.最便宜和流行的是cvs(見參考).它是一個靈活的工具,具胡TCP/IP訪問特性,可選擇性的提高安全性(通過用安全外殼SSH作為后端),卓越的腳本管理,甚至有圖形接口.許多其它VCS也將cvs作為標準去效仿,或基于它構(gòu)建新的功能.

            例外

            從始至終只花一周左右時間的一個程序員的項目或許可以不需要VCS而生存吧.

            參考

            [BetterSCM] · [Brooks95] $11, $13 · [CVS]

            4. 在代碼審閱上作投入

            摘要

            代碼審閱:更多雙眼睛將會帶來更好的質(zhì)量.展示你的代碼,并閱讀他人的.你們都將相互學(xué)習(xí)或受益.

            討論

            一個良好的代碼審閱過程在許多方面都對你的團隊有好處.它可以:
          11. 有益的平等的壓力可以增加代碼質(zhì)量.
          12. 可以找到bugs、移植性不好的代碼以及潛在的度量問題.
          13. 通過思想的互補培養(yǎng)形成的設(shè)計和實現(xiàn).
          14. 帶動新成員和初級者迅速提升能力.
          15. 在團隊中形成共同價值和團隊意識.
          16. 增加精英、信心、動機和專業(yè)自豪心.
          17. 許多開發(fā)商既不對代碼質(zhì)量和團隊質(zhì)量進行獎賞,也不投入時間和金錢鼓勵他們.希望我們從現(xiàn)在起幾年都不會食言,但我們感覺到這種趨勢正在慢慢改變,部分原因是由于對安全軟件的需求的增長.代碼審閱正有助于這種趨勢,另外也是一個極好的(和免費的)內(nèi)部訓(xùn)練方法.
            即使你的雇主還不支持代碼審閱方法,你也要增加管理知識(提示:要開始,給他們看這本書)以及無論如何要盡你最大努力去安排時間并引導(dǎo)審閱的進行.這時間是值得花的.
            將代碼審閱作為你的軟件開發(fā)周期的一項常規(guī)程序.如果你和你的隊友贊同基于激勵(也可能是挫折)的獎懲制度,就會好得多.
            不要做得太形式化了,寫一封簡單的郵件就足夠?qū)⒋a審閱做得很好了.這會使你更容易跟蹤自己的進程以及避免重復(fù).
            當(dāng)審閱他人的代碼時,你可能想在旁邊保留一個供參考的清單.竊以為一個好的清單可能正是你正在讀的這本書的目錄表.滿意吧!
            摘要:我們知道我們在給"唱詩班"布道,但是不得不說.你們的自負或自我主義也許討厭代碼審閱,但你們中的少量天才程序員喜歡它,因為它會有成效并使代碼更好,使程序更強健.

            參考

            [Constantine95] $10, $22, $33 · [McConnell93] $24 · [MozillaCRFAQ]
          18. posted @ 2005-11-22 13:46 可冰 閱讀(5718) | 評論 (9)編輯 收藏

            2005年11月20日 #

            自從國慶期間換Linux操作系統(tǒng)后,就再也沒有來寫過日志了,但我還是經(jīng)常上來看看的。
            我也不知道這是怎么回事,也不是很忙啊。在自己機子上弄了幾個網(wǎng)頁,就在上面和同學(xué)們互相交流,寫一些文章;但現(xiàn)在也沒有再弄了。
            我的激情好像總是很快的消逝。以后有過幾個項目的念頭,都只是剛做了個開始,花幾天或一周時間后就沒激情了?,F(xiàn)在也是剛找了幾個同學(xué)組織了一個小的團隊來寫點程序,但經(jīng)常這一個月左右后,發(fā)現(xiàn)我好像又想換其它的學(xué)習(xí)目標了。
            我為什么總是這樣子呢?
            現(xiàn)在心情又是周期性地落在了低谷,這一周幾乎什么都沒做。上課也都沒興趣。開了兩門選修課XML和ASP.NET;XML了解過,但不深入,老師講得太敷淺,想自己學(xué),又不好跟老師說,擔(dān)心說我看不起老師,但學(xué)分得要啊,不選又不行;ASP.NET也是用過的,但對它沒太大興趣,看了別人的教材,那些內(nèi)容基本上都知道的,通過考試是沒問題的,但還是放不下這好幾個破學(xué)分。我發(fā)現(xiàn)我真是給現(xiàn)在的教育套住了。
            得下個決心了!……好像我下的決心也不少啊,但也基本上都沒能堅持幾天,唉……!
            這樣的生活何時是個頭啊……
            posted @ 2005-11-20 15:00 可冰 閱讀(509) | 評論 (1)編輯 收藏

            2005年10月7日 #

            忽然發(fā)現(xiàn)自己這大學(xué)幾年都是在沒有任何的目標的生活著,沒有一點激情,有時候想著真是有點頹廢啊.想當(dāng)初為高考拼搏時是多么的有勁啊,能在那么長的時間里一直不放松.雖然大學(xué)生活已經(jīng)接近尾聲了,但還不算太晚,花點時間好好給自己確定一個目標吧!

            posted @ 2005-10-07 14:25 可冰 閱讀(382) | 評論 (0)編輯 收藏

            2005年9月29日 #

            上周,我花了很多心思使用模板寫了一個UTF-8與UNICODE相互轉(zhuǎn)換的功能(見文件code.rar),剛開始感覺還可以,但這幾天慢慢的覺得,為什么不直接提供兩個函數(shù)呢,這樣不是簡單方便嗎?我這樣的設(shè)計又能帶來額外的什么好處呢?剛開始我是想提供比較方便好用以及容易擴展與維護的代碼,但現(xiàn)在感覺到與直接提供C式的函數(shù)并沒有多少額外的好處.或許這樣的簡單功能根本就用不著這樣復(fù)雜的代碼吧.正如Eric Raymond對C++的評價一樣,它"使程序員傾向于寫復(fù)雜的代碼".
            我想大家看看我的代碼,給我一點意見和建議.
            posted @ 2005-09-29 20:34 可冰 閱讀(9368) | 評論 (10)編輯 收藏

            僅列出標題  下一頁
            99久久精品九九亚洲精品| 久久久久久一区国产精品| 久久久久亚洲AV成人网人人网站| 武侠古典久久婷婷狼人伊人| 精品国产乱码久久久久软件| 伊人久久大香线蕉av不卡| 久久久久久夜精品精品免费啦| 97精品久久天干天天天按摩| 久久香蕉国产线看观看乱码| 久久久久成人精品无码 | 久久久久久国产精品美女 | 久久99国产一区二区三区| 深夜久久AAAAA级毛片免费看| 一本久久a久久精品亚洲| 国产精品美女久久久久av爽| 亚洲?V乱码久久精品蜜桃| 国产精品久久久久AV福利动漫| 日本加勒比久久精品| 精品国产一区二区三区久久久狼| 精品欧美一区二区三区久久久| 亚洲国产精品无码久久久秋霞2| 国产ww久久久久久久久久| 无码人妻精品一区二区三区久久久| 国产精品午夜久久| 97久久天天综合色天天综合色hd | 人人狠狠综合久久亚洲88| 中文字幕精品久久| 久久国产精品免费一区| 国内精品伊人久久久久| 国内精品久久人妻互换| 久久精品国产99国产精品亚洲 | 久久精品国产精品青草| 色婷婷综合久久久中文字幕| 亚洲乱码日产精品a级毛片久久 | 久久久久久久女国产乱让韩| 九九热久久免费视频| 91精品日韩人妻无码久久不卡| 99久久99这里只有免费的精品| 无码人妻精品一区二区三区久久久| 亚洲AV乱码久久精品蜜桃| 精品久久久中文字幕人妻|