倫達文翻譯無聊寫 翻譯，合適晚上睡不著 翻譯人催眠用 翻譯社保證對進修沒幫助，對了解 C++
是什麼，有必然 翻譯混合感化；大師沒事看看就好，不消在乎。
◎貓抓老鼠－－沒有適合所有人的編程說話
常常見到很多人在問「我應當進修什麼語言？」 翻譯社近似這樣的問題，與
其說是「見仁見智」，不如說是「貓抓老鼠」。俗語說：「會抓老鼠的
貓，就是好貓。」對利用者而言，事實何種編程語言是最適合的，端視
其個人的需求及能力。如果始終拿不住耗子，這隻貓就算再名貴，再漂
亮，也沒什麼意義。
固然，反過來講，若是學不好某種語言，也沒必要太過悲觀，這或許暗示
您應該嘗試著轉往另外一片更合適自己的天空成長（另外一片天空，可能
是換養另一隻貓，也多是換抓分歧的老鼠，甚至多是不抓老鼠轉業
養老鼠） 翻譯社但萬萬莫要因自己的挫折經驗，就拼命進擊抵毀它，特別是
當「這隻貓」早已經被全部地球上業界頂尖的高手，和無數職業編程人
員及業餘玩家，證實了「它絕對是個好樣的」，適用價值無可庖代時，
那些私心的談吐，只不外暴露了指斥者自己的偏狹。
◎其他主流語言與 C/C++ 翻譯差別
在接頭 C++ 和 C 翻譯區分之前，也許先從「旁觀」者 翻譯角度，看看它們
「溝通」或「類似」 翻譯部分。此處首要 翻譯參照體是選擇一般通用型 翻譯編
程語言 翻譯社
1、現實運作的概念
首先，從現實運作的概念，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++
的「零本錢」原則：「利用者不該為他沒有效到的功能，付出履行期的
效力價值」 翻譯社因為不是每件事情都得靠泛化型別系統的多態性來解決
，而且解決的舉措也不該該只有一種（該說話所限制住 翻譯那一種）。
三、哲學的觀點
簡單的說，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 語言最大的離別，並
不在語法或功能的區別上，而是在於看待問題 翻譯基本思慮方式，也就是
所謂「思維方式」上的差異。
三、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有關翻譯的問題歡迎諮詢華頓翻譯社
留言列表
