• <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++ Program

            【ZT】delete this的使用

            posted @ 2008-06-03 18:17 lovedday 閱讀(6305) | 評論 (0)  編輯

            char, string, vector的內存使用比較
                 摘要: 測試結果:

            string array: times - 10000 memory - 1740k VM - 828k
            static char array: times - 10000 memory - 1740k VM - 820k
            char* array: times - 10000 memory - 2292k VM - 1368k
            string vector: times - 10000 memory - 1752k VM - 828k
            char* vector: times - 10000 memory - 2340k VM - 1420k

            可以看出,使用string以及vector或者靜態分配數組,內存消耗是比較少的,多次new小內存導致內存消耗明顯增多。  閱讀全文

            posted @ 2007-12-22 19:45 lovedday 閱讀(2565) | 評論 (4)  編輯

            Why don't we rewrite the Linux kernel in C++?
                 摘要: (ADB) Again, this has to do with practical and theoretical reasons. On the practical side, when Linux got started gcc didn't have an efficient C++ implementation, and some people would argue that even today it doesn't. Also there are many more C programmers than C++ programmers around. On theoretical grounds, examples of OS's implemented in Object Oriented languages are rare (Java-OS and Oberon System 3 come to mind), and the advantages of this approach are not quite clear cut (for OS design, th  閱讀全文

            posted @ 2007-10-30 15:20 lovedday 閱讀(861) | 評論 (0)  編輯

            【ZT】C++之父采訪手記
                 摘要: 在1998年的元旦,Bjarne Stroustrup(C++之父)接受了IEEE《計算機》雜志記者的專訪。編輯很自然的認為他會對于過去七年來使用他創建的語言進行面對對象設計做一個歷史性的回顧。而在這個專訪中,記者獲得了更有價值的新聞,但是最后編輯決定為了整個IT產業,這個稿子不能發表,但是就像其它被砍掉的新聞,往往還是弄得路人皆知的。

            這一篇是當時專訪的完全拷貝,沒有被編輯、刪改或者做過什么潤色處理,也沒有發布過,可能看起來不像常見的雜志文章,但這是實情。

            你會發現真正引人入勝的地方... ...   閱讀全文

            posted @ 2007-10-25 16:36 lovedday 閱讀(958) | 評論 (2)  編輯

            【ZT】你應當如何學習C++
                 摘要: Javascript是世界上最受誤解的語言,其實C++何嘗不是。坊間流傳的錯誤的C++學習方法一抓就是一大把。我自己在學習C++的過程中也走了許多彎路,浪費了不少時間。

            為什么會存在這么多錯誤認識?原因主要有三個,一是C++語言的細節太多。二是一些著名的C++書籍總在(不管有意還是無意)暗示語言細節的重要性和有趣。三是現代C++庫的開發哲學必須用到一些犄角旮旯的語言細節(但注意,是庫設計,不是日常編程)。這些共同塑造了C++社群的整體心態和哲學。  閱讀全文

            posted @ 2007-10-23 00:33 lovedday 閱讀(1106) | 評論 (0)  編輯

            【ZT】神話與謬誤:爭論C++前你應當知道什么
                 摘要: 最近寫了一篇關于C++0x Concepts的文章,意料之外地引起了一場小規模口水仗。回各位帖子的同時,回想這些年C++社群的大小爭論,覺得有必要把一些長久以來在C++爭論中出現的誤解列舉出來。

              …History became legend, legend became myth …- The Lord of the Rings

              哈雷將軍的笑話想必大家都聽過。一句話經口口相傳,每個人都根據自己的主觀意念加以潤色,修補,歪曲…到最后就面目全非。
              閱讀全文

            posted @ 2007-10-12 09:43 lovedday 閱讀(574) | 評論 (0)  編輯

            【ZT】C++批判(5)
                 摘要: 繼承關系是一種耦合度很高的關系,它與組合及一般化(genericity)一樣,提供了OO中的一種基本方法,用以將不同的軟件組件組合起來。一個類的實例同時也是那個類的所有的祖先的實例。為了保證面向對象設計的有效性,我們應該保存下這種關系的一致性。在子類中的每一次重新定義都應該與在其祖先類中的最初定義進行一致性檢查。子類中應該保存下其祖先類的需求。如果存在著不能被保存的需求,就說明了系統的設計有錯誤,或者是在系統中此處使用繼承是不恰當的。由于繼承是面向對象設計的基礎,所以才會要求有一致性檢測。C++中對于非虛擬函數重載的實現, 意味著編譯器將不會為其進行一致性檢測。C++并沒有提供面向對象設計的這方面的保證。  閱讀全文

            posted @ 2007-09-27 13:27 lovedday 閱讀(503) | 評論 (0)  編輯

            【ZT】C++批判(4)
                 摘要: C++允許在參數類型不同的前提下重載函數。重載的函數與具有多態性的函數(即虛函數)不同處在于:調用正確的被重載函數實體是在編譯期間就被決定了的;而對于具有多態性的函數來說,是通過運行期間的動態綁定來調用我們想調用的那個函數實體。多態性是通過重定義(或重寫)這種方式達成的。請不要被重載 (overloading)和重寫(overriding)所迷惑。重載是發生在兩個或者是更多的函數具有相同的名字的情況下。區分它們的辦法是通過檢測它們的參數個數或者類型來實現的。重載與CLOS中的多重分發(multiple dispatching)不同,對于參數的多重分發是在運行期間多態完成的。  閱讀全文

            posted @ 2007-09-27 13:24 lovedday 閱讀(392) | 評論 (0)  編輯

            【ZT】C++批判(3)
                 摘要: C++ARM中解釋說type-safe linkage并不能100%的保證類型安全。既然它不那100%的保證類型安全,那么它就肯定是不安全的。統計分析顯示:即便在很苛刻的情況下,C++ 出現單獨的O-ring錯誤的可能性也只有0.3%。但我們一旦將6種這樣的可能導致出錯的情況聯合起來放在一起,出錯的幾率就變得大為可觀了。在軟件中,我們經常能夠看到一些錯誤的起因就是其怪異的聯合。OO的一個主要目的就是要減少這種奇怪的聯合出現。  閱讀全文

            posted @ 2007-09-27 10:59 lovedday 閱讀(430) | 評論 (0)  編輯

            【ZT】C++批判(2)
                 摘要: 【P&S 94】中提到對于類型安全的檢測來說有兩種假設。一種是封閉式環境下的假設,此時程序中的各個部分在編譯期間就能被確定,然后我們可以對于整個程序來進行類型檢測。另一種是開放式環境下的假設,此時對于類型的檢測是在單獨的模塊中進行的。對于實際開發和建立原型來說,第二種假設顯得十分有效。然而,【P&S 94】中又提到,“當一種已經完成的軟件產品到達了成熟期時,采用封閉式環境下的假設就可以被考慮了,因為這樣可以使得一些比較高級的編譯技術得以有了用武之處。只有在整個程序都被了解的情況下,我們才可能在其上面執行諸如全局寄存器分配、程序流程分析及無效代碼檢測等動作。”(附:【P&S 94】Jens Palsberg and Michael I. Schwartzbach, Object-Oriented Type Systems, Wiley 1994)。  閱讀全文

            posted @ 2007-09-27 10:32 lovedday 閱讀(535) | 評論 (0)  編輯

            【ZT】C++批判(1)
                 摘要: 在所有對C++的批評中,虛擬函數這一部分是最復雜的。這主要是由于C++中復雜的機制所引起的。雖然本篇文章認為多態(polymorphism)是實現面向對象編程(OOP)的關鍵特性,但還是請你不要對此觀點(即虛擬函數機制是C++中的一大敗筆)感到有什么不安,繼續看下去,如果你僅僅想知道一個大概的話,那么你也可以跳過此節。【譯者注:建議大家還是看看這節會比較好】

            在C++中,當子類改寫/重定義(override/redefine)了在父類中定義了的函數時,關鍵字virtual使得該函數具有了多態性,但是 virtual關鍵字也并不是必不可少的(只要在父類中被定義一次就行了)。編譯器通過產生動態分配(dynamic dispatch)的方式來實現真正的多態函數調用。  閱讀全文

            posted @ 2007-09-27 02:51 lovedday 閱讀(712) | 評論 (4)  編輯

            【ZT】MFC五大批判
                 摘要: 算起來,我用Visual C++也有將近5年的歷史了。在這期間,我也曾涉獵過Visual Basic和Delphi,但都是淺嘗而止;Visual C++始終是我的主業。可是努力的成果如何呢?我用Delphi作出了十多個有規模的軟件,用VB--雖然我用在VB上的時間只有短短的兩三個月--也有兩個像樣的項目;然而,在我付出了最大熱情和最多努力的Visual C++上面,卻只作出了三個自己看得上眼的軟件。  閱讀全文

            posted @ 2007-09-26 14:32 lovedday 閱讀(753) | 評論 (0)  編輯

            【ZT】C++之父B. Stroustrup近期言論
                 摘要: [譯者按] Bjarne Stroustrup博士,1950年出生于丹麥,先后畢業于丹麥阿魯斯大學和英國劍橋大學,AT&T大規模程序設計研究部門負責人, AT&T、貝爾實驗室和ACM成員。1979年,B. S開始開發一種語言,當時稱為“C with Class”,后來演化為C++。1998年,ANSI/ISO C++標準建立,同年,B. S推出了其經典著作The C++ Programming Language的第三版。C++的標準化標志著B. S博士傾20年心血的偉大構想終于實現。但是,計算技術的發展一日千里,就在幾年前人們還猜想C++最終將一統天下,然而隨著Internet的爆炸性增長,類似Java、C#等新的、現代感十足的語言咄咄逼人,各種Script語言更是如雨后春筍紛紛涌現。在這種情況下,人們不禁有些惶恐不安。C++是不是已經過時了呢?其前景如何?標準C++有怎樣的意義?應該如何學習?我們不妨看看B. S對這些問題的思考。以下文字是譯者從Stroustrup1998年之后發表的若干文章、談話筆記中精選出來的,由于出處不一,內容多有重復,為保持完整,亦一并譯出。  閱讀全文

            posted @ 2007-09-11 14:45 lovedday 閱讀(475) | 評論 (0)  編輯

            公告

            導航

            統計

            常用鏈接

            隨筆分類(178)

            3D游戲編程相關鏈接

            搜索

            最新評論

            日韩AV毛片精品久久久| 囯产精品久久久久久久久蜜桃| 久久99精品国产麻豆宅宅| 久久综合久久久| 7777久久久国产精品消防器材| 无码久久精品国产亚洲Av影片| 久久久久久久久久免免费精品| 国产精品久久精品| 国内精品久久久久久99| 亚洲精品乱码久久久久久按摩 | 国产日韩久久免费影院| 国产亚洲欧美精品久久久| 久久99精品久久久久久野外| 国产成人精品久久一区二区三区av| 久久夜色精品国产| 久久受www免费人成_看片中文| 久久久久久久综合日本| 久久久久99精品成人片欧美| 麻豆亚洲AV永久无码精品久久| 无码国内精品久久人妻| 欧美午夜A∨大片久久 | 久久激情亚洲精品无码?V| 99精品久久精品一区二区| 国产69精品久久久久APP下载| 国产精品久久久久a影院| 精品多毛少妇人妻AV免费久久| 国产精品久久久久久一区二区三区| 久久精品国产男包| 伊人久久大香线蕉成人| 久久精品女人天堂AV麻| 韩国无遮挡三级久久| 性做久久久久久久久老女人| 国产精品成人久久久久久久| 久久成人国产精品二三区| 久久精品国产清高在天天线| 亚洲人成网亚洲欧洲无码久久| 久久久久久久久久久免费精品| 久久精品成人免费观看97| 精品无码久久久久久久久久| 欧美日韩中文字幕久久伊人| 国产精品gz久久久|