專業筆譯社
更加具有彈性和擴充性，同時不損失、甚至提拔效率）（獨一的錯誤謬誤，呃……，大
C 及 C++ 是今朝最受迎接的說話之「二」翻譯常人常常覺得二者差不多，
的氣概完全分歧翻譯在多數人的心目中，C 是簡練、工致、短小精桿的，而 C++，固然
C++ 用以具現泛型編程設計模式的體式格局，是引入樣版（template）及其他相互
效力要求的，堪稱最「標準」的函式庫 STL(Standard Template Library) 。有了
c = -a/4 + b * 2;
BigInt a翻譯社 b, c;
、明白、彈性、擴充性、效力……等等的目的。例如以 const 和 inline 儘可能取
C++ 承續了 C，固然也支援函式指標，但 C++ 程式的風格，其實不鼓勵利用指
常常去處理複雜、過於低階的陣列、指標、位元等等運算（固然有必要時仍是該這麼
一點只是想申明，C++ 不但支援四種首要的編程技術，更主要的要害在於：C++ 對
某些物件底子用不到，卻必須在函式每次履行的時辰去配置記憶體。
利。以上這段話或者可以看成詮釋「封裝」的註腳，這也就是所謂的 object-based
如果
3. object-oriented paradigm
，不敷完全。事實上，C 和 C++ 的差距非常大翻譯
Essential COM 的作者 Don Box 在書中提到：C++ 其中一個主要的理念，就
不會比一樣功能的 C 程式碼最好化後要差。
就更美好、容易閱讀、理解，一致性高，就不容易出錯，利便保護翻譯總之，封裝機制對
之卻步）的其中一個原因就在於：C 具有指標的設計，可以在最大限度的範圍內
總之，以上所會商的每項特征，都使得 C++ 的程式設計，在根本上就和 C 語言
，就不多接頭了。不外有一點可以提出來：只有少數的說話支援完全的多重繼續，
一個，然後就可以簡單的計算像 1^100 + 2^100 + ... + 100^100 = ? 這類問題：
不能說沒出缺點（沒出缺點就暗示沒有進步空間了），但我還是只能用獨一的「偉大」
sum += i^100;
為程式設計的思維觀念更前進了，所以又有更邃密精美的區隔）。概略地說，前者是指
曾示意，他認為 Java 早晚也會加入雷同 C++ 的 template 的機制，這是任何一個
for (BigInt i=1; i<=100; ++i)
4. generic paradigm
言歸正傳，所謂 object-based paradigm 和 object-oreinted paradigm ，
甚至，若是你喜歡 BASIC 的次方（^）符號表式法，你可以在 C++ 中本身設計
太多太多，每一項，都是為了讓程式設計更嚴謹、明白、語法更自然、簡練、一致、
其次，繼承和動態繫結，也就是 object-oriented 編程手藝，建築在封裝，
引申意義則是：「C++ 兼具了效力與彈性」翻譯舉個例子，萬國翻譯公司們都知道，在以前
代 C 的巨集，引入 const、mutable、new、delete 等關頭字，加強物件和記憶體管
幫你解決很多小麻煩。另外，如果你的 BigInt 類別設計允當，它履行時的效率，
b = "458349057395730974539451048634826832629683342310298457";
合營的機制（如 RTTI，動態型別辨識），以及在泛型編程的根本上，符合了嚴酷的
固然，連 C++ 的發明人都說，可以不消學 C，直接學 C++（敝人在之前一
一致明白的語法表達、加倍具有彈性和擴充性，且更有效率的函式物件（function
例如不謹慎把 BigInt 和浮點數混用；像這類的問題，在 C 上通常都沒有舉措完全
就是支援物件導向的 C。固然，不能說這些講法是錯的；是的，這些沒錯，只是
斷成長進化的過程當中，直至今朝為止，已綜合歸納出，而且實現了四種分歧，而
結（dynamic binding）的機制翻譯
篇答複佈告中曾接頭過，這個說法應當只是指說話自己，而不是指直接透過 C++
而明白，例如
或，常聽到有人說，C++ 是 C 的超調集（或 C 是 C++ 的子集），或，C++
概略地說，C 本身十分精簡，保存字極少，語法簡練、設計氣勢派頭偏向切確、
沒有供應多重繼續，而 Java 也只支援有限型式的多重繼續翻譯
擴充性更高。
那麼 C++ 到底有何不同呢？用一句最簡單的話說，貫串 C++ 的整個理念
事實上，C++ 所有分歧於 C 的功能，都是為了達成上述的更嚴謹、平安、一致
（包括以位元）操作記憶體的緊密性。
而言，都是不成能實現的。而且，透過 C++ 封裝機制和其他如異常處理的支援，
而今朝，泛型編程的手藝在 C++ 上的實現應當也是最成熟的。B.S.（C++的發現人）
2. object-based paradigm
模式。很幸運地，在 C++ 還不是很完整時，由於全部說話在各方面貫穿了兼具彈性
問：「真的嗎？若是是真的，C++ 究竟是怎麼做到的？」沒錯，並且這就是之前我
又相輔相成的程式設計的思惟模式：（因為沒有準確的字面譯詞，先寫英文，後
解決，只能好自為之。但在 C++ 上，如果種別設計夠嚴謹，編譯／聯結器每每可以
體組件幻想最重要的第一步。
了生產力。（當然前提是要學得會）
理念付諸實現翻譯
這個限制。明顯，C++ 的體例比較公道，因為強迫把宣佈放在最前面，極可能
種編程思惟，C 只提拱了第一種，也就是我們常聽到的「程序（功能）導向」模
乖巧的編排組織起來。
固然，完全的多重繼承增添了語法的複雜度，利用上不見得是長處翻譯但提出這
在诠釋之前，先說一點，C 和 C++ 的不同之處就在於，以上所列 C++ 的四
面提過的「利用者不需要為他沒有用到的功能支付效力的價值」，如許的幻想。
c %= d;
是讓使用者可以自訂型別，而且在處置自訂型別時，和操作內建型別一樣天然、便
每種編程技術的支援，都到達最完整的水平。正因為它完整，才能儘可能貼近前
式－－把功能切割成恰當的小模組，在 C 語言中就是一個一個小函式，再按需求
進修程式設計的思惟方式）；但，要體味 C++ 的精華，先了解 C 的特征和風格
int d = 4;
一致的方式，模塑抽象的思惟世界。這部分在觀念和技術上都有相當程度的複雜性
這兩者便是幾年前一般所謂的「物件導向」編程模式（現在之所以有所辨別，是因
面再解釋）
們即將計議的主題，C++ 就是靠著另外三項（C 說話並不支援的）編程技術，將此
像這樣的語法表達，在沒有或對 object-based 編程手藝支援不敷完整的說話
1. procedural-based paradigm
所謂全面是指：編譯／聯絡器提供更嚴謹、更平安的檢查，語法表達更一致明白、
STL，程式設計師不消再每次自己寫 tree、list、stack、queue ...等等，也不需要
object），來取代 C 的函式指標的手藝。
編程翻譯透過 C++ 類別（class）的封裝機制，你可以讓程式說話表達地更自然、一致
是事實翻譯並且，事實不只如斯，可以說，幾乎在每個處所，C++ 都全面超出了 C（
最後，generic paradigm，泛型編程翻譯這是相當晚近才興起的程式設計的思惟
以上只是個很小的例子，總之，C++ 為了告竣兼容效力和彈性的理念，在不
，就是：「利用者不應為他沒有效到的功能付出效力的代價」。這句話直接的
理、引入 exception 異常處理的機制、引入 namespace 定名空間的機制……等等，
封裝（encapsulation）的編程模式；爾後者涵蓋了繼承（inheritance）及動態繫
client（利用這些種別的人）而言，是極為便當而不可或缺的，幾乎可以說是邁向軟
而 C++ 正是個中之一；其他如 Objective C, Object Pascal, Smalltalk 等，並
舉例而言，在 C++ 中，你可以寫一個支援四則運算的超大整數 BigInt 的種別，
，自由靈動地操控記憶體翻譯而在嚴謹的法式導向編程思惟的年月，像 C 這類支援
必須特殊提到一點，C 之所以受許多程式設計師青睞（也同時令另外一些人望
靈巧。它同時具有高階語言流程節制與資料處置的便利性，和低階語言直接
指向函式的指標這類禁斷技術的語言，會在眾說話百家爭鳴下脫穎而出，也就不
a = "-3298347290354325472309573874327432094739742071561";
做），而可以定心的使用兼具效能、移植性和擴充性的 STL 組件和演算法，大大晉升
BigInt sum = 0;
， C 說話中所有物件（變數、構造）的宣告都要放在最前面，在 C++ 則沒有
太意外了。
向函式的指標。在 C++ 中，提供了一種更嚴謹、具有型別平安（type safe）、更
來形容它。
邁向成熟而完整的說話天然的趨向翻譯
和效力的精力，所泄漏的潛力被一致看好，泛型編程理念的很早就被引入了 C++，
也就是 object-based 的根本，讓程式設計師可以更進一步以嚴謹、平安，天然、
，照樣很有扶助的。
概就是，它艱巨的水平，也周全超越了 C）（天下沒有白吃的午飯）。你應該會想
整數）、Matrix（矩陣）、DateTime ……等等的類別。語法表達天然、明確，程式
讓它在使用上與內建型別毫無劃分：
本文來自: http://blog.xuite.net/edison901/documents/3753230-C+%E5%92%8C+C%2B%2B+%E7%9A%84%E5%B7%AE%E5%88%A5+--有關各國語文翻譯公證的問題歡迎諮詢萬國翻譯公司02-23690931
留言列表
