bushcollyqr

英語翻譯中文無聊寫 翻譯，合適晚上睡不著 翻譯人催眠用 翻譯社包管對學習沒扶助，對了解 C++ 是什麼，有必然的混淆感化；大家沒事看看就好，不消在意 翻譯社 ◎貓抓老鼠－－沒有合適所有人的編程語言 經常見到許多人在問「我應當學習什麼說話？」。近似如許的問題，與 其說是「見仁見智」，不如說是「貓抓老鼠」。俗話說：「會抓老鼠的 貓，就是好貓。」對利用者而言，究竟何種編程說話是最合適的，端視 其小我的需求及能力。要是始終拿不住耗子，這隻貓就算再寶貴，再漂 亮，也沒什麼意義。 當然，反過來講，如果學欠好某種語言，也沒必要過分灰心，這也許默示 您應該測驗考試著轉往另外一片更合適自己的天空成長（另一片天空，可能 是換養另外一隻貓，也可能是換抓分歧 翻譯老鼠，乃至多是不抓老鼠改行 養老鼠）。但萬萬莫要因自己的挫折經驗，就拼命進犯抵毀它，尤其是 當「這隻貓」早已被整個地球上業界頂尖的高手，和無數職業編程人 員及業餘玩家，證實了「它絕對是個好樣的」，實用價值無可庖代時， 那些私心 翻譯言論，只不外暴露了指斥者自己的偏狹。 ◎其他主流說話與 C/C++ 翻譯差異 在計議 C++ 和 C 翻譯區別之前，也許先從「旁觀」者 翻譯角度，看看它們 「不異」或「相似」的部分。此處主要的參照體是選擇一般通用型 翻譯編 程說話。 一、現實運作 翻譯觀點 起首，從實際運作 翻譯概念，C 及 C++ 都是循傳統 翻譯體例，透過編譯器 和保持器，直接產生原生的機器碼（Machine Code 或 Native Code） ，而新一代的編程說話，有很多（例如 Java 翻譯公司 C# 等）是先透過翻譯轉 成 bytecode，然後再由虛擬機械（Virtual Machine）來執行。 固然很多人認為 Java、C# 等說話依賴虛擬機械執行的體式格局，效率欠安 ，不外客觀的說，其實這種手藝在某種意味上是比力先進的觀念，它最 主要的優勢顯示在移植性方面 翻譯社至於效率的問題多半出在各平台間 翻譯差 異太大，而實作手藝則顯然還沒有完全成熟。（但這是可以克服的） 可能已有人開始焦急了 翻譯社「照如許說，C/C++ 不是後進了嗎？」其實 並沒有。本質上來看，二者是一樣 翻譯 翻譯社因為大可以把 C++ Complier 當 成虛擬機，只是它不是由一家公司或少數特定人士所規範的，而且絕大 大都的平台（機器和功課系統）上，都是支持 C/C++ 的 翻譯社而像 J2SE, .NET 這些架構則是 Sun 或 MS 所擬定的。 （甚至可以如許認為：C/C++ 的虛擬機器是許多不同廠商、組織各自實 作的，只是它們儘量遵守 ISO ANSI C/C++ 翻譯標準，而 JVM 又或 CLI 這些器材，雖然說也是開放 翻譯，但實則操縱在 Sun 和 MS 手中。） 現實上，C/C++ 與 Java, C# 等最大的分別，並非體現在虛擬機械的 觀念或作法上，而是體現在利用層面。光學會 C/C++ 語言，乃至它們 的標準程式庫後，通常幹不了什麼有效的事 翻譯社一個 C/C++ 程式人員， 至少得熟習一種 GUI 框架、一種 IPC 框架及一種 Database 框架，才 大致可以說能處理大部分 翻譯利用問題。 固然，不是說用 Java 翻譯公司 C# 就不必學會這些工具，只是這些功能有很多 都已成為該語言（框架）標準 翻譯一部分，在學習說話的時候，平常就 會順便學到運用的架構。但在 C/C++ 中，所謂的「標準程式庫」，卻 只規範了最最根基的 I/O，檔案處理，和經常使用的基礎演算法等等，其他 都必須仰賴第三方或特定廠商的程式庫的支援，而這些器材則沒有所謂 翻譯標準，又經常受限於特定的平台情況，在取捨上比較不容易。 2、型別系統的概念 C/C++ 說話都是採用傳統 翻譯靜態型別系統（static type system），而 很多新說話，為了便當物件導向特性 翻譯運作，是採用基於單根擔當的泛 化型別系統，例如 Object Pascal, Java, C# 都是如此。 靜態型別系統的特征，就是不強迫改變利用者自訂型別（UDT: User- defined Type）的記憶體結構，而且許可在 stack 中配置 UDT 變量（ 也就是「物件」，但由於在 C 說話中，沒有真正物件導向的觀念，因 此以「變量」來指稱）。此外，在靜態型別系統中，「型別」和「變量 」之間，是壁壘分明的，你沒法在編譯期產生變量，也弗成能在執行期 產生新的「型別」。 相對的，基於單根繼續的泛化型別系統，例如在 Delphi 的 VCL 架構中 ，所有 翻譯 VCL 元件，都繼承自 TObject，這就使得某些特別 翻譯功能，例 如以 ClassName 獲得物件的現實型別資訊，就很容易實現 翻譯社Java 和 C# 等也都是如斯。某些語言乃至內建 MetaClass 的特性，型別自己也可以 看成變量，在履行期創立新 翻譯、或修改既有的型別，這些都是根源於泛 化型別系統的根本 翻譯社相形之下，在靜態型別系統中，很多特別的功能， 說話自己不直接支持，就必需自己去實現，或仰賴函式庫。 固然，靜態型別系統的最大優勢，就是執行期的效力 翻譯社這也就是 C/C++ 翻譯「零本錢」原則：「利用者不該為他沒有效到的功能，付出執行期的 效力價值」。因為不是每件事情都得靠泛化型別系統 翻譯多態性來解決 ，而且解決的設施也不該該只有一種（該說話所限制住 翻譯那一種）。 3、哲學的概念 簡單的說，C/C++ 翻譯設計哲學是把程式人員視為「成人」 翻譯社它認為程式 人員知道本身在幹什麼，而不是把程式人員當成「小孩」乃至「犯人」 ，需要特殊的珍愛，乃至預設程式人員必然會犯某種毛病，所以它儘量 賜與最大的自由及彈性，而不是強迫的限制或規範。 例如，包羅內建型別，使用者自訂型別，和指標在內，它不逼迫你必然 要將變量（物件、陣列或指標）初始化，不強迫你搜檢陣列的範圍，不 逼迫指標必然要指向正當 翻譯位址，它甚至許可你在各型別之間任意轉換 翻譯社 又例如，C/C++它其實不內建垃圾回收器（GC: Garbage Collection）， 它認為惟有程式人員自己，才能決議什麽時候方是償還動態申請記憶體 翻譯最 適當時機，而不會在背後監督著一舉一動，幫忙收破爛。 固然，假如只是因為「自由」和「彈性」，而要支出高昂的經管和維護 的價格，那是不值得的。C/C++ 相對於其他語言，顯得較為「寬鬆」， 首要照樣基於效力方面的考量。。-> 翻譯社|,-> 翻譯公司|的-> 翻譯很多基於物件導向特征的新語言，雖然 增添了平安和供應某些狀況下的便當性，但是一旦面臨目生或特異 翻譯問 題，既有的對象和規範，沒法直接套用時，過量 翻譯限制或「預設立場」 ，就很可能反釀成了累贅。 從這個角度，也能夠說，C/C++（其實首要指 C++）其實不認為存在著某 種最完美的方案，可以解決所有「運用條理」的問題，因此其實不在語言 條理去規範這些問題應當怎麼解決，而是把解決方案交給應用層（程式 庫）去負責。說話本身只供給各類抽象的設計機制（介面），讓程式庫 翻譯利用能儘量與語言系統的氣概一致。 ◎ 偉大的 C 語言 就筆者小我 翻譯認知，C 絕對稱得上是一個偉大的語言 翻譯社它最偉大的地方， 在於語言自己，優越地對映了 Von Neumann 所提出的現代計較機的模 型（主要是：二進位制、序列執行，和將程式與資料都儲存在機械裏 ）。C 說話的指標（pointer），對記憶體把持 翻譯簡潔、自由、及靈動 性，就充份體現了這一特點 翻譯社透過 C 語言，利用者可以較為直覺地運 用抽象 翻譯數學觀念，來編寫程式，而沒必要直接面臨晦澀 翻譯機械指令。 由於與機器模型之間的高度映照關係，和說話本身的精鍊，相較於機 器說話，C 除具有高度的移植性，在效能方面的浮現也相當凸起，大 部分的情形下，幾乎不遜於機械語言幾何。許多大型的系統，除少部 份的焦點代碼利用機械語言以外，絕大部份都是以 C 說話編寫 翻譯 翻譯社 以如今 翻譯眼光，固然 C 語言不是大大都運用範疇 翻譯首選（當然，照舊 有不少範疇是非常 prefer C 說話的），但透過 C 語言的進修，對於 理解程式在機械中現實 翻譯運作情形，有莫大 翻譯幫助，也能夠說是理解程 式 翻譯基礎。任何人若想成為編程高手，精曉 C 說話，可以說是最少 翻譯 條件 翻譯社在全部資訊科學領域中，C 說話更是佔有極其環節、沒法磨滅 翻譯 歷史性地位。 ◎從 C 到 C++ 固然其實筆者是很想下「偉大的 C++」這樣的題目，但實際上如果不是 秉承了 C 說話 翻譯精華，C++ 是不可能有今天的成績的。另外一方面，C++ 的某些不盡人意的地方（例如語法的過於複雜），也是因為秉承了 C 語 言的特點才釀成的。 事實 C++ 和 C 有什麼分歧呢？本來，在 ANSI C99 的標準之前（C89） ，C++ 至少有 95% 乃至可以說 99% 是兼容於 C 說話的，是以可以說 C 說話是 C++ 的一個子集。但在 C99 以後，某些 C 說話新 翻譯特性， 特殊是動態長度 翻譯 Array，使得這種大體上的兼容性被毀壞了，也就是 說，把 C 當做 C++ 翻譯子集，這樣的說法可能要有所保存了。如果未來 ，C 和 C++ 再度泛起某些重大的不合，也不是什麼令人不測的事情。 1、強化「型別安全」－－對型別系統的周全改進 很多觸及語法細節的地方就略過了 翻譯社在此只提出一個較重要的部份，是關 於 C++ 與 C 的底子不同的地方： int *v = ...; void *p = v; int *p2 = p; // 正當 翻譯 C 程式碼，但在 C++ 中不正當 簡單的說，C++ 不允許 void * 隱式轉換為隨便型別 T 翻譯指標。但在 C 語言中，這是正當的 翻譯社 C++ 禁止上述操作的來由，是為了強化「型別平安」。程式中一旦利用 void *，就等於自動抛卻了編譯器對型別的自動查抄與查對動作，也就 是放棄了型別安全。而明知不好，C++ 依然支援 void * 這類用法 翻譯原 因，首要是為了兼容於 C，但由於 void * 隱式換為肆意型另外 T *， 這類用法其實太危險，所以在 C++ 中被制止了。 抱負的 C++ 程式，是不該該呈現 void * 這類用法的 翻譯社C++ 之父 B.S. 就曾指出，除低階程式以外，應該儘量避免使用 void *，如果非得 用 void * 不可，通常代表你的設計出了某些問題 翻譯社 細心調查，C++ 的每項根本設施，都有提升型別安全的意味在其中。 例如： １引入 bool 型別，避免混淆。（主要問題在函式 overload 時） ２激勸以 0 而非自行界說的 NULL 巨集等代表空指標 翻譯社（B.S.大和另 　一名 Herb Sutter 大，在 2003 年末提出新增添 nullptr 環節字， 　但不知道 C++03 是不是有經由過程）。 ３引入 const，讓「常數性」成為與型別不行朋分 翻譯一部分，除晉升 　平安，讓編譯器承擔檢核的責任以外，也有助於代碼的優化。（是以 　後來 C 語言也跟進採用。） ４引入 const, inline 等用法，減少非必要巨集 翻譯使用。（因為展開 　巨集是預處置器 翻譯動作，沒有經由過程編譯器，也就沒有型別平安可言）。 ５引入 reference 機制，簡化指標的語法，並有用減少指標（尤其是 　兩層以上的複雜指標）的使用。 ６引入 new 和 delete，取代 malloc 和 free，把動態記憶體配置的 　工作，提拔至說話層級，削減強迫轉型的利用（另外一首要目 翻譯是為了 　共同 operator overloading，晉升介面的一致性） 翻譯社 ７引入新的 static_cast 翻譯公司 const_cast 等關頭字，鼓動勉勵儘量削減強迫 　轉型的利用。 ８引入 function/operator overloading 機制，讓同名函式及各種運 　算子，可依據不同 翻譯操作型別，實現不同的動作。強調「型別」也是 　函式具名 翻譯一部分，告竣介面一致性，並使 UDT 能像內建型此外操 　作一樣天然。 這些每一個小地方，都可以看出 C++ 為了強化「型別安全」，所付出的 用心和努力，固然除制止 void * 的隱式轉型以外，根基上沒有限制 C++ 利用者延用舊的 C 說話的舊式習慣寫法，但筆者認為，認識型別系 統的特征，並隨時意識著「型別平安」，是把握精良 C++ 編程氣概 翻譯最 主要觀念。 2、在「思維方式」上的差別 程式語言處理的不外乎資料結構及演算法，STL 的發明人也說過：「程 式基於切確 翻譯數學 翻譯社」前面提過，C 說話偉大的地方，就是它十分傑出地 對映到機器模型，免除了直接使用機器說話的艱澀 翻譯社 也就是說，C 程式人員沒必要去費心 register 辦理、記憶體定址等等極 度低階 翻譯細節問題 翻譯社其所思慮的，多半像是「我應當用什麼演算法，把 某幾段特定記憶體內 翻譯資料掏出來，顛末如何的運算後，再存到特定的 記憶體區段去…… 翻譯社」這類把運算和存取操作的細部具體動作，轉換為 抽象的數學思慮 翻譯流程，素質上依然是非常貼近機器模型的。而這樣 翻譯 氣概，不但反應在 C 程式碼上，更多半根深蒂固地植入 C 程式人員 翻譯 思惟方式內。 隨著資訊科學的發展，愈來愈多的應用問題，需要利用編寫程式來處置懲罰 ；人們發現，大部分利用程式所利用的演算法和資料佈局，是極為有限 的。另外一方面，編寫程式說話的經常使用技能，卻已積累地相當做熟了， 程式人員需要支出更多心力的，不再是某個典型 翻譯演算法或資料佈局， 應當如何實現，若何處置懲罰；而在於，如何將問題的本身，適當地轉換為 程式語言。 因此，一種讓程式說話可以或許以「切近待解決的問題」的體例來思考，而 不再只是侷現於「貼近機器模型」的思想，就應運而生。簡單地說，它 就是發源於 70 年月（乃至更早），在 80~90 年月起頭快速成長，直至 本日，雖不再新穎，卻仍屬如日中天 翻譯「物件導向」的觀念。 由於物件導向（OO: Object-Orientd） 翻譯觀念是如斯氾濫，乃至已上 升到哲學的條理，幾近沒有一個比較新 翻譯語言（80年代以後），不支援 它的特性，所以這裏也就不多介紹了。只是要指出一點， C++ 也好，或 其他支援物件導向特征的編程說話也好，它們與 C 說話最大的別離，並 不在語法或功能的區別上，而是在於看待問題 翻譯基本思考方式，也就是 所謂「思維方式」上 翻譯差別 翻譯社 3、multi-paradigm C++ 和 C 說話，在觀念上最大 翻譯分歧的地方，就是，C++ 是支撐 multi- paradigm 的編程說話。以下面所示，C 說話及傳統的 Pascal 說話， 是所謂 procedual-based 翻譯編程說話，而 Java, C# 等較新 翻譯說話，則 是 object-oriented 翻譯編程說話（OOPL）。 至於 C++，它現實上是個支援 multi-paradigm 翻譯編程語言，因為它不 僅保存了 C 的法式導向的編程，更重要的是它沒有沒有為了要支援 OO， 而破壞基於 C 語言的靜態型別系統，因此它供給的 ADT（abstract data type）機制，與擔當和履行期繫結等 OO 特征的機制是互相獨立的。這使 得 C++ 在 OO 翻譯執行期多型之外，罕有地提供了壯大 翻譯編譯期多型 翻譯機 制，也就是一般稱為「泛型編程」的手藝。 procedual-based（eg: C, Pascal...） object-oriented（eg: Objective C, Object Pascal 翻譯公司 Java, C#...） C++: procedual-based object-based(ADT) \ / \ \ / \ \ / \ generic object-oriented(OO) 由上面的簡單示意圖可看出，泛型（generic）的編譯期多型的特征，不 止對應在 ADT 上，也能夠直接對應到法式導向 翻譯編程，例如 C++ 標準程 式庫所供應的泛型演算法，就大部分是以函式而不是 class 來顯現的， 現實上，全部 C++ Standard Library，除 I/O 的部分，幾近完全沒有 用到 OO 的履行期多型的特性（更多的是 ADT 和 template） 翻譯社 此外，或許有人會提出，其實 Java 或 C# 也是支援 generic 編程的，是 沒錯，Java 也有類似 C++ 翻譯樣板容器的功能，但實際上是用「代換法」 做 翻譯，並沒有真正產生新的型別，是以它沒法到達 C++ template 那樣可 以有型別客製化（特別化: specialization），或與其他抽象化機制合作 （例如繼承、甚至遞迴） 翻譯多樣化的能力，並不算真正意義上的編譯期多 型 翻譯社實際上，Java 和 C# 語言所採行的單根繼承的泛化型別系統，早就先 天限制它們不合適朝編譯期多型的標的目的成長，它們比力接近純潔 翻譯 OOPL 翻譯社 C 說話的思慮體式格局著重於資料運算和記憶體存取的動作，物件導向 翻譯思慮 體例，則是將問題分化成分歧的抽象概念（class），讓利用者專注在概 念與概念間之的關聯，能從一個整體 翻譯大的偏向，去存眷問題，避免過早 陷入細節，見樹而不見林 翻譯社 同時，良好的設計，是當需求有所改變時，只需要修改、調整部份的模組， 就能夠完成工作，沒必要整體性的翻修，牽一髮而動全身。這也是物件導向 設計的主要精力，有一個專門的領域 DPs（Design Patterns），它與特 定程式語言無關，就是在研究面對各種問題需求的典型解決方式，目下當今學 物件導向設計必然會接觸到它。 至於，C++「多思惟面向」（multi-paradigm） 翻譯特征，又是若何影響編 程的思慮體式格局呢？ 這裏舉個《Modern C++ Design》第七章的例子。Smart Pointer 翻譯成長 念頭，是為了避免直接操作指標所帶來 翻譯危險性，但跟著各類不同的需求 ，它的實作細節也就有所分歧。例如：它能不克不及與其他容器類（例如標準 程式庫中的 vector 翻譯公司 list 等）共用，和利用 翻譯細節若何？是否允許取 得原始指標？是否對各種操作動作進行檢查，如何檢查？乃至，是不是支援 多緒程式平安地操作……等等 翻譯社 假如將各類需求組合都列出清單，再一個一個實作，必將沒完沒了。最理 想 翻譯體例，是讓程式員自由選擇各類「需求策略」，讓編譯器主動產生相 應的程式碼。這類設計乍看來是遙不可及的理想，但實際上已經做到了。 這就是 Loki 函式庫所提供的實作品 class template SmartPtr： template < typename T 翻譯公司 template <class> class OwnershipPolicy = RefCounted, class ConversionPolicy = DisallowConversion, template <class> class CheckingPolicy = AssertCheck, template <class> class StoragePolicy = DefaultSPStorage > class SmartPtr; 由於牽涉的選擇項目過多，這裏只诠釋 OwnershipPolicy，也就是現實物 件具有權 翻譯策略，它預設是 RefCounted，也就是參用計數 翻譯劃定規矩。但也 可以根據需求的不同，選擇其他的具有權策略，例如：RefCountedMT、 DestructiveCopy、DeepCopy、……等等。利用體例以下： class User {...}; typedef SmartPtr<User, RefCounted> UserPtr; 如斯，UserPtr 就變成類似 boost::shared_ptr<User> 的感化，可以和 標準容器合作，而實現 Java、C# 語言常見的功能。又假如： class Manager {...}; typedef SmartPtr<Manager, DestructiveCopy> ManagerPtr; 現在，MangerPtr 則和 std::auto_ptr<Manager> 一樣，採取所謂「摧毀 式複製」的語義，也就是同時只有一個 ManagerPtr 可以真正把持統一份 Manager 類型的實體物件。 現實上，SmartPtr 的實現牽扯到 ADT、多重繼承、編譯期多型等等 翻譯特 性，它應用了一種叫 policy-based 的設計觀念。這與其他程式語言或是 DPs 所標榜的 OO 翻譯特征，或所謂「優越設計」的最終目的，並沒有分歧 ，一樣是將分歧的概念自力分化，再巧妙組合起來 翻譯社只不外，在 C++ 中， 除傳統 OO 履行期多型 翻譯手藝以外，還多了強大 翻譯編譯期多型的支援， 使得不僅「物件」（資料結構和演算法），可以在執行期被彈性處理，就 連「型別」（概念）的本身，在編譯期，也可以自由的拔取整合 翻譯社這對程 式碼編寫的簡練、靈動性和履行效力，都能帶來很大 翻譯提拔 翻譯社

引用自: https://www.ptt.cc/man/C_and_CPP/D8D2/DA94/DDBB/M.1127480887.A.47F.html有關翻譯的問題歡迎諮詢華頓翻譯社