joyceevelynps｜痞客邦

阿布卡茲文翻譯比來狂翻人力銀行哈哈請問～上面的語言能力水平聽、說、讀、寫的略懂、中等、精曉大師感覺劃分是到什麼樣的水平呢？或廠商招人，略懂、中等、精曉需要什麼樣的程度呢？ ~~~~ 萬國翻譯公司感覺"聽""讀"算是比力容易掌握的部分，最難的就是"說""寫" 即便過N1、N2的人會全填精曉嗎？我本身是四年前考舊制三級沒過，以後沒有再考沒有專程翻書，大部分從日劇動畫歌詞漸漸漸漸撿，撿到幾個字記幾個翻譯吃動畫生肉、聽歌手廣播，自認為可以到6~7成。浏覽歌手blog或許9成吧，感激她們寫得很糊口化翻譯小說就難了。有一次跟日本人措辭的機會，或許是聊的是配合喜好的整體"略微"聊得起來。不外文法很糟。 "寫"的部份，想在歌手blog留言可是怕文法搞錯主受相反很糗，幾句就搞良久。這樣我有聽-中等說-略懂讀-中等寫-略懂的水平嗎？ -- 萬國翻譯公司的科系不太需要外語能力，要也是要求英文；我是全填略懂，反正也沒有人要略懂，日文純潔填爽的讓履歷不那麼空XD (鄙人超廢怯...)

(繼續閱讀...)

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

▲top

Nov 22 Thu 2018 09:49
[心得] C++ 與 C 的特征及區分

阿薩姆文翻譯無聊寫的，合適晚上睡不著的人催眠用翻譯保證對學習沒幫助，對了解 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++ 的「零本錢」原則：「使用者不該為他沒有效到的功能，支付執行期的效力價值」翻譯因為不是每件工作都得靠泛化型別系統的多態性來解決，並且解決的法子也不該該只有一種（該語言所限制住的那一種）。 3、哲學的概念簡單的說，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++ 再度泛起某些重大的不合，也不是什麼使人不測的工作。一、強化「型別安全」－－對型別系統的周全改良許多涉及語法細節之處就略過了。在此只提出一個較主要的部分，是關於 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++ 編程氣概的最重要觀念翻譯二、在「思維方法」上的差別程式說話處置懲罰的不過乎資料佈局及演算法，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 履行期多型的手藝以外，還多了壯大的編譯期多型的支援，使得不但「物件」（資料構造和演算法），可以在履行期被彈性處置懲罰，就連「型別」（概念）的自己，在編譯期，也能夠自由的拔取整合翻譯這對程式碼編寫的簡練、靈動性和履行效力，都能帶來很大的提拔翻譯