vqr5reevesv8｜痞客邦

克萬亞瑪文翻譯無聊寫的，適合晚上睡不著的人催眠用翻譯包管對進修沒匡助，對了解 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++ 的每項基礎舉措措施，都有提拔型別平安的意味在個中。例如：１引入 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 履行期多型的技術之外，還多了強大的編譯期多型的支援，使得不但「物件」（資料結構和演算法），可以在執行期被彈性處理，就連「型別」（概念）的自己，在編譯期，也可以自由的拔取整合。這對程式碼編寫的簡練、靈活性和履行效力，都能帶來很大的提升。

(繼續閱讀...)

anthonjhrb3aa 發表在痞客邦留言(0) 人氣()

▲top

Mar 09 Fri 2018 03:20
[評價] 106

冰島文翻譯※ 本文是不是可提供臺大同學轉作其他非營哄騙途？（須保留原作者 ID）（是／否／其他前提）：是哪一學年度修課： 106-1 ψ 講課教師 (若為多人合授請寫開課教師，以利便收錄) 張麗麗 λ 開課系所與講課對象 (是不是為必修或通識課 / 內容是否與某些佈景相關) 中文系大一必修 δ 課程大概內容按課本目錄： Chapter 1: What Is Language? Chapter 2: Morphology: The Words of Language（構詞學） Chapter 4: The Meaning of Language (Semantics and Pragmatics) （語義學、語用學） Chapter 5: Phonetics: The Sounds of Language（語音學） Ω 私心推薦指數(以五分計) ★★★★★ 想要有體系地熟悉說話學根基概念者：5星除閱讀教科書還想聽教員增補者：5星想多瞭解英語與漢語者：5星外系但對語言有樂趣者：5星善于考試不善于告訴者：5星整體：5星 η 上課用書(影印講義或是指定教科書) 原文書Fromkin翻譯社 Rodman & Hyams. 2013. An Introduction to Language. 10th edition.，可於總圖B1臺大出書品中心以優惠價格購得翻譯另發放上課簡報和補充資料。 μ 上課體例(投影片、團體討論、教員教授教養氣概) 首要由先生口頭教學，搭配投影片重點提醒。時常書寫黑板彌補關鍵概念。授課進度依循課本內容，輔以簡報彌補延伸資訊或漢語案例翻譯鼓勵事前預習課文，會放置預習進度。老師講課親熱有趣，對日常說話和學術專業皆有良好的掌握，擅長率領同學一起思考翻譯能快速清楚地回覆同窗的疑問，若趕上沒掌控的問題，必會查詢資料後於下週向大師分享。另安助教指點時間為需要的同窗解惑。 σ 評分方式(給分甜嗎？是紮實分？) 作業15%、小考20%、期中考30%、期末考35%翻譯強調作業和小考某方面是為拉抬大師的成績，協助不那麼擅長申論題的同窗。曾有人透露表現，「她之前的記實只給一個A+欸。好恐怖！」但本學期應不是這麼一回事翻譯 ρ 考題型式、作業體例 1、作業(15%) 一學期一次，共兩題。教員會分派每人需回答的標題問題，多是課本章節後的習題或本身出的補充題目翻譯批改完將所有人的回答統合成一個檔案，供自行下載，裡面的內容皆有可能成為期中、期末考題。 2、小考(20%) 本學期一共6次小考，取4次最佳成績計分翻譯講堂上先生會不厭其煩地幫各人溫習，只要賣力就有根基分。 3、期中、期末考(65%) 約14個大題，課本內容、上課彌補、同學回答皆可以是考題來曆翻譯 ω 其它(是否注重出席率？若是為外系選修，需先有什麼根蒂根基較好嗎？老師個性？加簽習慣？嚴禁遲到等…) 天成翻譯公司是對說話學有愛好的外系生。考量到臺大開設語言學的系所有中文系和外文系，固然同為一學年的課程，但前者為大一必修上下各兩學分，後者為大二必修上下各三學分。加上中文系會更強調漢語的語言學分析，與生活方圓較能接軌，所以選擇加簽了這堂課。我在第三週才很冒昧地寫加簽信，沒想到老師在學生人數超標的前提下仍慷慨答允了。原擔心此舉有些冒昧，以後才發現本班有許多非本科系的學生，乃至還有旁聽生翻譯可見只要有心，先生肯定很接待大家前來修習的。 Ψ 總結麗麗老師授課活躍生動，風格了了曉暢，常與學生互動，營建傑出的講授氛圍。學識淵博又善舉例，能針對課程內容彌補延長知識，且統整及闡釋能力強，總能在短時候內解答學生迷惑，使人滿載而歸。構思之習題富足趣味，引領學生多加留心糊口中奇妙的語言現象，並認真批改學生功課，一一點評回覆，足見用心。分外放置助教時候，供給需要同窗自立應用，乃貼心之舉。