契瓦文翻譯無聊寫 翻譯,合適晚上睡不著的人催眠用 翻譯社保證對學習沒扶助,對了解 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++
翻譯「零成本」原則:「利用者不應為他沒有效到的功能,支出履行期的
效力價格」。因為不是每件事情都得靠泛化型別系統的多態性來解決
,而且解決的設施也不應該只有一種(該說話所限制住 翻譯那一種) 翻譯社
三、哲學的概念
簡單的說,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++ 的每一項根本舉措措施,都有提拔型別安全的意味在此中。
例如:
1引入 bool 型別,避免混淆。(主要問題在函式 overload 時)
2鼓動勉勵以 0 而非自行界說 翻譯 NULL 巨集等代表空指標。(B.S.大和另
一名 Herb Sutter 大,在 2003 歲尾提出新增添 nullptr 關鍵字,
但不曉得 C++03 是不是有通過) 翻譯社
3引入 const,讓「常數性」成為與型別不可朋分的一部份,除提升
安全,讓編譯器承當檢核的責任之外,也有助於代碼 翻譯優化 翻譯社(因此
後來 C 說話也跟進採用。)
4引入 const, inline 等用法,削減非需要巨集 翻譯利用。(因為睜開
巨集是預處置懲罰器的動作,沒有經由過程編譯器,也就沒有型別平安可言) 翻譯社
5引入 reference 機制,簡化指標 翻譯語法,並有用削減指標(特別是
兩層以上的複雜指標) 翻譯利用。
6引入 new 和 delete,庖代 malloc 和 free,把動態記憶體設置裝備擺設的
工作,提拔至說話層級,削減強迫轉型的利用(另外一首要目標是為了
共同 operator overloading,提拔介面的一致性)。
7引入新 翻譯 static_cast, const_cast 等樞紐字,激勸儘量削減強迫
轉型的利用。
8引入 function/operator overloading 機制,讓同名函式及各類運
算子,可根據不同的操作型別,實現不同 翻譯動作。強調「型別」也是
函式簽字的一部分,達成介面一致性,並使 UDT 能像內建型另外操
作一樣自然。
這些每個小處所,都可以看出 C++ 為了強化「型別安全」,所付出的
專心和盡力,固然除禁止 void * 翻譯隱式轉型以外,根基上沒有限制
C++ 使用者延用舊的 C 說話的舊式習慣寫法,但筆者認為,了解型別系
統的特征,並隨時意識著「型別安全」,是把握良好 C++ 編程氣勢派頭的最
主要觀念 翻譯社
二、在「思維方式」上的差異
程式說話處置 翻譯不外乎資料佈局及演算法,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有關翻譯的問題歡迎諮詢華頓翻譯社
- Oct 04 Wed 2017 07:42
[心得] C++ 與 C 的特征及區分
文章標籤
全站熱搜
留言列表
發表留言