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