青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

天行健 君子當自強而不息

▲ C++ Program

【ZT】delete this的使用

posted @ 2008-06-03 18:17 lovedday 閱讀(6333) | 評論 (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 閱讀(2583) | 評論 (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 閱讀(875) | 評論 (0)  編輯

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

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

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

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

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

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

posted @ 2007-10-23 00:33 lovedday 閱讀(1151) | 評論 (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 閱讀(582) | 評論 (0)  編輯

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

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

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

posted @ 2007-09-27 13:24 lovedday 閱讀(400) | 評論 (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 閱讀(436) | 評論 (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 閱讀(540) | 評論 (0)  編輯

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

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

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

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

posted @ 2007-09-26 14:32 lovedday 閱讀(762) | 評論 (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 閱讀(483) | 評論 (0)  編輯

公告

導航

統計

常用鏈接

隨筆分類(178)

3D游戲編程相關鏈接

搜索

最新評論

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            亚洲视屏在线播放| 国产精品久久福利| 亚洲国产婷婷香蕉久久久久久99| 亚洲一区二区三区四区在线观看| 91久久综合亚洲鲁鲁五月天| 国产日韩欧美在线播放不卡| 国产精品www.| 国产精品毛片在线| 欧美mv日韩mv国产网站app| 久久久久久一区| 欧美电影免费观看高清| 欧美片在线观看| 国产精品美女久久福利网站| 国产情侣一区| 亚洲国产高清一区| 一本大道久久a久久精品综合| 亚洲一区二区三区四区五区午夜| 欧美一区二视频在线免费观看| 玉米视频成人免费看| 激情综合中文娱乐网| 亚洲激情国产精品| 一本色道久久综合精品竹菊 | 久久精品导航| 欧美精品日韩三级| 性色av一区二区三区| 亚洲高清视频一区二区| 99re6这里只有精品视频在线观看| 一区二区三区久久| 久久人人97超碰国产公开结果| 欧美激情性爽国产精品17p| 国产精品视频一二| 日韩午夜激情电影| 蜜臀a∨国产成人精品| 一区二区三区视频在线| 久久综合久久综合久久| 国产精品夫妻自拍| 亚洲欧洲一区二区三区在线观看 | 欧美影院在线| 日韩午夜av| 欧美+日本+国产+在线a∨观看| 国产精品久久久久婷婷| 亚洲激情成人网| 可以免费看不卡的av网站| 一区二区三区四区蜜桃| 欧美sm视频| 久久久在线视频| 久久精品一区二区国产| 国产精品极品美女粉嫩高清在线| 精品91免费| 欧美亚洲视频在线观看| 最新国产成人av网站网址麻豆| 欧美在线播放| 国产日韩欧美另类| 欧美中文字幕视频| 亚洲综合大片69999| 欧美视频免费在线| 亚洲视频在线看| 亚洲人成7777| 欧美日本久久| 一本高清dvd不卡在线观看| 欧美高清视频在线播放| 久久免费少妇高潮久久精品99| 国产欧美一区二区精品秋霞影院| 亚洲免费视频一区二区| 99精品视频一区| 欧美性色综合| 欧美亚洲专区| 欧美一级免费视频| 韩国一区电影| 欧美激情1区| 欧美国产日韩一区二区在线观看| 亚洲高清不卡一区| 91久久久亚洲精品| 欧美视频日韩| 久久aⅴ乱码一区二区三区| 亚洲欧美日韩在线一区| 国产在线一区二区三区四区| 久久一区二区三区av| 久久久精品tv| 99国产一区| 亚洲综合第一页| 欧美人与禽性xxxxx杂性| 国产亚洲欧美aaaa| 久久成人国产| 亚洲一区在线播放| 国内精品免费在线观看| 免费观看成人鲁鲁鲁鲁鲁视频 | 亚洲国产欧美另类丝袜| 欧美日韩精品伦理作品在线免费观看| 夜夜嗨av色综合久久久综合网 | 亚洲电影天堂av| 欧美日韩三级在线| 久久精品亚洲| 欧美国产综合一区二区| 亚洲一区在线看| 久久精品国产96久久久香蕉| 亚洲国产日韩在线一区模特| 亚洲欧洲在线一区| 国产精品丝袜久久久久久app| 久久精品一级爱片| 美日韩精品视频| 亚洲欧洲99久久| 麻豆国产精品一区二区三区 | 久久久久国产免费免费| 一区二区高清视频| 久久精品首页| 亚洲欧美日本日韩| 欧美xxx成人| 久久久久久夜| 欧美视频二区| 亚洲高清激情| 狠狠色狠狠色综合人人| 一区二区三区**美女毛片| 在线观看日韩一区| 新狼窝色av性久久久久久| 亚洲免费观看在线视频| 欧美诱惑福利视频| 亚洲欧美日本国产专区一区| 蜜桃久久精品乱码一区二区| 欧美一区二区在线看| 欧美日韩精品在线| 亚洲国产精品一区二区www在线| 国产三区二区一区久久| 99精品视频免费观看视频| 亚洲人成人一区二区三区| 欧美在线啊v| 欧美伊人久久大香线蕉综合69| 欧美全黄视频| 亚洲国产小视频在线观看| 亚洲天堂av电影| 国产精品国产三级国产专播品爱网 | 亚洲国产欧美一区二区三区同亚洲 | 国产综合久久久久久鬼色| 最新日韩欧美| 亚洲精品美女| 久久麻豆一区二区| 欧美在线3区| 国产精品夜色7777狼人| 99www免费人成精品| 日韩视频三区| 欧美精品日韩三级| 亚洲精品视频在线播放| 亚洲精品日韩激情在线电影| 久久亚洲精品一区二区| 欧美**字幕| 亚洲精品免费电影| 欧美激情精品久久久久| 亚洲理论电影网| 亚洲一区二区高清| 国产精品剧情在线亚洲| 亚洲欧美日韩另类| 久久久高清一区二区三区| 国产午夜精品在线观看| 欧美亚洲三区| 欧美91大片| 亚洲理伦在线| 欧美午夜国产| 性18欧美另类| 欧美激情第三页| 一区二区三区欧美亚洲| 国产精品国产三级国产a| 亚洲欧美日韩爽爽影院| 猫咪成人在线观看| 夜夜嗨av一区二区三区网站四季av | 在线亚洲精品| 欧美一区二区三区四区在线| 国产日韩精品一区| 久久久久久亚洲精品杨幂换脸| 欧美成人黄色小视频| 一二美女精品欧洲| 国产欧美婷婷中文| 欧美成年人视频网站| 在线视频精品一| 免费看成人av| 亚洲欧美久久久久一区二区三区| 国产欧美日韩一区二区三区在线观看| 久久久久99| 一区二区激情| 欧美成人一区二免费视频软件| 妖精成人www高清在线观看| 国产欧美日韩不卡| 欧美激情1区2区3区| 午夜精品久久久久久久久| 亚洲高清色综合| 久久成人精品视频| av成人免费在线观看| 好吊妞这里只有精品| 欧美日韩日本视频| 久久尤物视频| 亚洲一区二区三区在线看| 欧美国产日韩一区二区三区| 亚洲欧美经典视频| 日韩午夜av电影| 在线不卡a资源高清| 国产精品美女视频网站| 欧美激情第9页| 久久亚洲风情| 久久riav二区三区| 蜜臀av性久久久久蜜臀aⅴ| 亚洲视频www|