建站
咨詢
售后
建站咨詢
新聞中心
與以前的C競(jìng)爭(zhēng)者(例如C ++，D，Java，C#，Go，Rust和Swift)的比較
從很多方面來(lái)說(shuō)，我整個(gè)編程生涯都像是在等待C的替代產(chǎn)品的漫長(zhǎng)等待。20年前，盡管我用C ++。 隨著時(shí)間的流逝，我了解到C ++是一個(gè)復(fù)雜的怪物，無(wú)論我讀了多少本書，都永遠(yuǎn)無(wú)法馴服。
我認(rèn)為Yossi Kreinin和他的C ++常見問(wèn)題解答(https://yosefk.com/c++fqa/)在總結(jié)我對(duì)C ++討厭的各個(gè)方面都做得很好。
因此，在成為一名專業(yè)的C ++程序員時(shí)，我總是著眼于其他選擇。 第一個(gè)有希望的替代品是D。D最初看起來(lái)很有前途，但經(jīng)過(guò)仔細(xì)檢查，我認(rèn)為D實(shí)際上只是一個(gè)根本上不好的主意的清理版本。 C ++的主要問(wèn)題之一是它的接收器語(yǔ)言設(shè)計(jì)方法。
當(dāng)用C和Lua實(shí)現(xiàn)一個(gè)簡(jiǎn)單的游戲引擎時(shí)，我意識(shí)到與C ++相比，同時(shí)保留這兩種語(yǔ)言的思路實(shí)際上更少了。 它給我?guī)?lái)了對(duì)C的重新熱愛。盡管有其所有局限性，C是一種相當(dāng)簡(jiǎn)單的語(yǔ)言，可以提供很多控制。
Java和C#在許多方面只是嘗試重新實(shí)現(xiàn)C ++。他們可能使事情變得更簡(jiǎn)單，但最終卻陷入了虛擬機(jī)和90年代面向?qū)ο蟮木幊坛醋髦小２皇钦f(shuō)Java或C#不好，其中很多可能與那些支持臃腫的IDE和過(guò)度設(shè)計(jì)的語(yǔ)言的相關(guān)社區(qū)有關(guān)。
C簡(jiǎn)單性的回歸
從Google轉(zhuǎn)到Go是對(duì)多余的C ++，D，Java和C#的歡送。Go將我們帶回到了起點(diǎn)，回到了C。Go重新設(shè)想了如果不冒險(xiǎn)走C ++道路，C可能會(huì)是什么。我們得到的是一種簡(jiǎn)單的語(yǔ)言，它修復(fù)了我在C語(yǔ)言中經(jīng)常遇到的許多問(wèn)題。
但是故事還沒有結(jié)束。 緊隨Go之后，我們得到了Rust。 最初，我認(rèn)為Rust實(shí)際上是D應(yīng)該一直以來(lái)的目標(biāo)。 對(duì)C ++應(yīng)該是什么的真正的重新思考。 Rust保持了低級(jí)控制，高級(jí)抽象機(jī)制和手動(dòng)內(nèi)存管理，但增加了無(wú)與倫比的類型安全性。 一切看起來(lái)都太好了，難以置信。
坦率地說(shuō)，我認(rèn)為是。我記得能夠在兩天內(nèi)用Go編寫一些不錯(cuò)的程序。朱莉婭，我目前的最愛也有些相似。另一方面，學(xué)習(xí)Rust就像學(xué)習(xí)Haskell。在做任何有用的事情之前，只需了解許多概念和理論即可。
如果C ++教會(huì)了我任何東西，那就是要重視簡(jiǎn)單性，而Rust不會(huì)這樣做。
后來(lái)，我從互聯(lián)網(wǎng)上許多Rust用戶的評(píng)論中學(xué)到了，Rust重復(fù)了C ++的主要缺點(diǎn)之一。它的編譯時(shí)間確實(shí)很慢。我認(rèn)為沒有什么比等待C ++編譯破壞我編程的樂趣了。聽起來(lái)好像Rust更糟了。那是一個(gè)破壞交易的因素。
Swift-我想愛的語(yǔ)言
我20年來(lái)一直是蘋果的忠實(shí)粉絲。 我很喜歡Cocoa GUI庫(kù)，并在沒有iPhone之前就對(duì)Objective-C進(jìn)行了編程，突然，每個(gè)人和他們的寵物都在用Objective-C進(jìn)行編程。
是的，Objective-C有點(diǎn)笨拙，但它的簡(jiǎn)單性具有一定的美感。 與C ++不同，它是對(duì)C語(yǔ)言的相當(dāng)簡(jiǎn)單的補(bǔ)充。 根據(jù)經(jīng)驗(yàn)，您實(shí)際上可以真正快速地教初級(jí)開發(fā)人員Objective-C。
因此，Swift的發(fā)布讓我覺得我已經(jīng)達(dá)到了編程的必殺技。最終，一種非?，F(xiàn)代的語(yǔ)言與Objective-C很好地集成在一起，因此我們?nèi)匀豢梢允褂煤馨舻腁pple庫(kù)，例如Cocoa。
Swift從Rust那里借來(lái)了很多想法，從很多方面來(lái)說(shuō)，我認(rèn)為我們終于為普通人獲得了Rust?？梢栽谙喈?dāng)短的時(shí)間內(nèi)學(xué)會(huì)Swift。
但是我在Swift方面的經(jīng)歷好壞參半。 即使在今天，我也仍然無(wú)法正確表達(dá)語(yǔ)言的問(wèn)題，因?yàn)樗坪蹩梢越鉀Q很多問(wèn)題。
我將iPhone應(yīng)用程序從Objective-C移植到了Swift。 我最好的經(jīng)歷之一是Swift僅僅由于嚴(yán)格的類型系統(tǒng)就發(fā)現(xiàn)了一大堆錯(cuò)誤，這些系統(tǒng)捕獲了在Objective-C中不可見的問(wèn)題，而這在編譯時(shí)至少是關(guān)于類型的，這是眾所周知的。
與C ++，C#和Java相比，我會(huì)說(shuō)Swift是更好的語(yǔ)言。 Swift幾乎解決了我所有有關(guān)C ++的特定問(wèn)題。 但是我每次使用Go時(shí)都意識(shí)到，編寫Go程序比Swift有趣得多。 但是Go的錯(cuò)誤處理有點(diǎn)糟糕，它重復(fù)了具有空指針的百萬(wàn)美元錯(cuò)誤。 Swift避免了這兩個(gè)問(wèn)題。
上次與Julia在一起很長(zhǎng)時(shí)間后，我回到Swift時(shí)，看到Swift的一些問(wèn)題變得更加清晰：
Swift語(yǔ)法不適合函數(shù)式編程
從Objective-C繼承的Smalltalk啟發(fā)式語(yǔ)法在面向?qū)ο蟮木幊讨泻芎玫毓ぷ?，但是?duì)于函數(shù)式編程卻非常糟糕。將函數(shù)用作一等公民時(shí)，您無(wú)需費(fèi)心確保參數(shù)名稱正確。
面向?qū)ο蟮木幊毯秃瘮?shù)式編程之間的停戰(zhàn)。Swift試圖為兩個(gè)不同的主人服務(wù)，并為此遭受痛苦。在進(jìn)行非常實(shí)用的樣式編程時(shí)，您希望您的函數(shù)主要是自由函數(shù)。這些更易于傳遞并在函數(shù)設(shè)置中使用。
但是Swift最終主要是面向OOP人群，將函數(shù)放在方法中。 一旦完成了許多函數(shù)編程，這就會(huì)變得很麻煩。
Zig適合編程領(lǐng)域的何處?
因此Swift從來(lái)沒有真正成為我最終的通用編程語(yǔ)言。如果我想以更高的抽象級(jí)別進(jìn)行編程，獲得高性能并完成工作，我將選擇Julia。
但這仍然為C之類的替代品留下了未填補(bǔ)的空間。朱莉婭(Julia)不能真正取代C。它吞噬了內(nèi)存，無(wú)法產(chǎn)生小的二進(jìn)制文件，不適合使其他語(yǔ)言可以使用的庫(kù)。您不想使用它來(lái)創(chuàng)建OS內(nèi)核或進(jìn)行微控制器編程。
Go和Rust都真的接近于替換C。Go擺脫了使用C的簡(jiǎn)單性和使用感。但是它使用垃圾回收并不能完全替代C。與Java相比，在Go中對(duì)內(nèi)存使用的更多控制仍然是毫無(wú)價(jià)值的，因?yàn)槟梢垣@得指針，并且實(shí)際上可以創(chuàng)建自己的輔助分配器。
Rust降低了手動(dòng)的內(nèi)存分配，但是未能復(fù)制C的簡(jiǎn)單性和感覺。也許這兩種語(yǔ)言之間是否有什么可以填補(bǔ)的空間?
確實(shí)有。 我認(rèn)為這就是Zig。 Zig比Go更復(fù)雜，但比Rust更易于學(xué)習(xí)和使用。
但是，這樣的Zig總結(jié)并不能使語(yǔ)言公正。Zig為表帶來(lái)了很多新想法，這很有道理，并且使Zig編碼的體驗(yàn)非常獨(dú)特。但是在深入探討之前，讓我們先看一下基礎(chǔ)知識(shí)。
正確掌握基礎(chǔ)知識(shí)
如果我們要學(xué)習(xí)另一種類似C的語(yǔ)言，我們將無(wú)法重復(fù)C ++最糟糕的情況，例如糟糕的編譯時(shí)間。 Zig如何解決這些問(wèn)題?
我遇到了V編程語(yǔ)言的創(chuàng)建者Alexander Medvednikov進(jìn)行的測(cè)試。這是編譯具有400 K函數(shù)的文件的測(cè)試：
- C 5.2秒 gcc測(cè)試
- C ++ 1分25秒 g ++ test.cpp
- Zig 10.1秒 Zig build-exe test.zig
- Nim 45秒 nim c test.nim
- Rust 30分鐘 rustc test.rs 后Rust停止
- Swift 在30分鐘的swiftc測(cè)試后停止
- D 6分鐘后 segfault dmd test.d
- V 0.6秒 v test v
Rust，Swift和D都失敗了。Medvednikov用更少的行數(shù)對(duì)這些語(yǔ)言進(jìn)行了進(jìn)一步的測(cè)試，Rust再次表現(xiàn)出了最差的預(yù)期。
正如您在列表中所看到的，Zig是最杰出的演員。 盡管很難不注意到V語(yǔ)言會(huì)在不到一秒鐘的時(shí)間內(nèi)完成所有操作。 這使我想起更詳細(xì)地探索V。 快速掃描表明它可以手動(dòng)分配內(nèi)存，泛型和可選(必須明確允許使用空指針)。
Zig內(nèi)存分配
如果不進(jìn)行手動(dòng)內(nèi)存管理，您將無(wú)法使用C語(yǔ)言。進(jìn)行C風(fēng)格編程的人都希望這樣做。如果我不需要，那么我可以為Julia編程。
Zig沒有提供Rust所提供的那種最高的安全性，但是如果不這樣做，它所獲得的是一個(gè)對(duì)于初學(xué)者來(lái)說(shuō)更容易掌握和使用的模型。
需要在Zig中分配內(nèi)存的任何內(nèi)容都將分配器作為參數(shù)。 因此Zig非常明確地說(shuō)明了何時(shí)需要內(nèi)存管理。
這是我編寫的一個(gè)簡(jiǎn)單函數(shù)，它使用32位無(wú)符號(hào)整數(shù)n并將其拆分為十進(jìn)制數(shù)字：
- fn decimals(alloc: *Allocator, n: u32) !Array(u32) {
- var x = n;
- var digits = Array(u32).init(alloc);
- errdefer digits.deinit();
- while (x >= 10) {
- try digits.append(x % 10);
- xx = x / 10;
- }
- try digits.append(x);
- return digits;
- }
請(qǐng)注意，必須使用分配器分配用于保留各個(gè)十進(jìn)制數(shù)字的數(shù)組數(shù)字，該分配器是十進(jìn)制函數(shù)的參數(shù)。
這就是Zig真正的光芒所在。 確保您不會(huì)忘記分配內(nèi)存在C語(yǔ)言中很難。而且很容易以錯(cuò)誤的位置結(jié)束內(nèi)存。 Zig從Go復(fù)制了延遲概念。 但是除了推遲它還有errdefer。 如果您不了解Go，那么從本質(zhì)上講，延遲是將行或代碼塊的執(zhí)行推遲到函數(shù)退出之前的一種方法。
為什么這么好? 因?yàn)樗鼓梢源_保某些代碼得以運(yùn)行，而不管退出該函數(shù)之前使用了什么復(fù)雜的if-else語(yǔ)句。
- errdefer digits.deinit();
上面的行與正常的Go延遲有所不同，因?yàn)橹挥性诜祷劐e(cuò)誤代碼的情況下，它才會(huì)執(zhí)行。因此，如果一切正常，那么它將永遠(yuǎn)不會(huì)運(yùn)行。
在呼叫站點(diǎn)，我們將使用常規(guī)延遲來(lái)確保我們不會(huì)忘記釋放分配給數(shù)字的內(nèi)存。
- const digits = try decimals(allocator, 4123);
- defer digits.deinit();
- for (digits.items) |digit| {
- try print("{},", .{digit});
- }
從我在Zig玩游戲方面的有限經(jīng)驗(yàn)，我會(huì)說(shuō)這是一個(gè)很好的系統(tǒng)。分配器和defer的結(jié)合使用使您非常清楚要分配和釋放內(nèi)存的位置，同時(shí)可以輕松正確地進(jìn)行分配。
C兼容
許多類C語(yǔ)言的問(wèn)題是它們無(wú)法與C配合使用。這意味著從該語(yǔ)言調(diào)用C函數(shù)應(yīng)該很容易，而從C對(duì)該語(yǔ)言調(diào)用函數(shù)應(yīng)該很容易。
此外，您編寫程序的一般方式應(yīng)該與C完全兼容，因此您不必創(chuàng)建較大的C抽象級(jí)別。例如。C ++對(duì)C語(yǔ)言不是很友好，因?yàn)闆]有大量包裝就無(wú)法在C中使用典型的C ++庫(kù)。
但是Zig非常C，因?yàn)樗鼪]有暴露C不會(huì)得到的奇怪的東西。 結(jié)構(gòu)中沒有vtable(C ++中的虛擬函數(shù)表)。 沒有C知道如何調(diào)用的構(gòu)造函數(shù)或析構(gòu)函數(shù)。 也沒有任何例外，C也會(huì)在捕獲方面遇到困難。
從Zig使用C很簡(jiǎn)單。 實(shí)際上，Zig的創(chuàng)建者會(huì)聲稱Zig比C本身更擅長(zhǎng)使用C庫(kù)。
- const c = @cImport({
- @cDefine("_NO_CRT_STDIO_INLINE", "1");
- @cInclude("stdio.h");
- });
- pub fn main() void {
- _ = c.printf("hello\n");
- }
如您所見，Zig解析C頭文件并包含來(lái)自C的類型和函數(shù)沒有問(wèn)題。實(shí)際上Zig是完全成熟的C編譯器。您可以根據(jù)需要使用Zig編譯C程序。
同樣，將Zig函數(shù)暴露給C也很容易。這是一個(gè)Zig函數(shù)，采用32位整數(shù)并返回32位整數(shù)。
- export fn add(a: i32, b: i32) i32 {
- return a + b;
- }
通過(guò)將export放在它的前面，可以使我們與程序鏈接的C代碼可以訪問(wèn)它。實(shí)際上，我們的主要功能是在C代碼部分中定義的，并且使用了Zig中定義的功能。
- #include
int32_t add(int32_t a, int32_t b); - int main(int argc, char **argv) {
- assert(add(42, 1337) == 1379);
- return 0;
- }
這意味著您可以輕松地開始將較大的C程序的某些部分轉(zhuǎn)換為Zig并繼續(xù)進(jìn)行編譯。 移植程序時(shí)，這是一項(xiàng)非常強(qiáng)大的功能。 過(guò)去讓我很容易地從Objective-C移植到Swift的原因是，我可以一次用Swift版本替換一個(gè)Objective-C方法，進(jìn)行編譯并看到一切仍然有效。
實(shí)際上，通過(guò)允許您自動(dòng)將C程序轉(zhuǎn)換為Zig代碼，Zig使其變得更加容易。 這是Zig編譯器內(nèi)置的：
- $ zig translate-c foobar.c
當(dāng)然，該代碼不是最佳的，可能有點(diǎn)混亂。但這有點(diǎn)像使用Google翻譯進(jìn)行自然語(yǔ)言翻譯。這是一個(gè)很好的起點(diǎn)，可以節(jié)省大量的體力勞動(dòng)。您可以稍后自己手動(dòng)修復(fù)細(xì)節(jié)。
極簡(jiǎn)主義
極簡(jiǎn)主義首先吸引了很多人使用C編程。 這就是Go正確的事情，并使編程變得很高興。 您可以輕松地將整個(gè)程序放在腦子里。
現(xiàn)在，如果您開始閱讀Zig并查看我在這里給您的源代碼示例，它可能看起來(lái)很復(fù)雜。 有些語(yǔ)言結(jié)構(gòu)可能看起來(lái)很奇怪。 可以很容易地感覺到它是一種復(fù)雜的語(yǔ)言。
因此，弄清Zig不支持的所有事物實(shí)際上非常有用：
- 沒有類繼承，例如C ++，Java，Swift等。
- 通過(guò)Go之類的接口沒有運(yùn)行時(shí)多態(tài)性。
- 沒有泛型。 您不能像在編譯時(shí)檢查的Swift中那樣指定通用接口。
- 沒有函數(shù)重載。您不能多次使用不同的參數(shù)編寫具有相同名稱的函數(shù)。
- 沒有異常拋出。
- 沒有閉包。
- 沒有垃圾收集。
- 沒有用于資源獲取的構(gòu)造函數(shù)和析構(gòu)函數(shù)是初始化(RAII)。
但是，通過(guò)巧妙地使用一些核心功能，Zig能夠提供幾乎相同的功能：
- 類型可以在編譯時(shí)像對(duì)象一樣傳遞。
- 標(biāo)簽工會(huì)。在其他編程語(yǔ)言中也稱為求和類型或變體。
- 函數(shù)指針。
- 實(shí)數(shù)指針和指針?biāo)阈g(shù)。
- Zig代碼可以在編譯時(shí)部分評(píng)估。您可以使用comptime關(guān)鍵字將代碼標(biāo)記為在編譯時(shí)可執(zhí)行。
- 函數(shù)和類型可以與結(jié)構(gòu)相關(guān)聯(lián)，但不能物理存儲(chǔ)在結(jié)構(gòu)中，因此C代碼不可見。
在Zig中模擬泛型
例如。通過(guò)利用在編譯時(shí)運(yùn)行代碼的能力，在Julia中創(chuàng)建了類似于模板的內(nèi)容。洛里斯·克羅(Loris Cro)有一篇很好的文章更詳細(xì)地描述了這一點(diǎn)。我將僅使用該文章中的示例來(lái)快速了解該想法。
我們可以定義例如一個(gè)稱為L(zhǎng)inkedList的函數(shù)，該函數(shù)只能在編譯時(shí)調(diào)用，該函數(shù)采用鏈表中元素的類型，然后返回包含以下元素的鏈表類型：
- fn LinkedList(comptime T: type) type {
- return struct {
- pub const Node = struct {
- prev: ?*Node = null, next: ?*Node = null, data: T,
- };
- first: ?*Node = null, last: ?*Node = null, len: usize = 0,
- };
- }
這利用了結(jié)構(gòu)可以是匿名的事實(shí)。 您不需要給他們起個(gè)名字。 但是，此功能需要一點(diǎn)包裝。 注意這一部分：
- pub const Node = struct { prev: ?*Node = null, next: ?*Node = null, data: T,};
這里有許多Zig特定功能在起作用，需要一些解釋。 在Zig中，可以在定義結(jié)構(gòu)時(shí)將值分配給結(jié)構(gòu)成員。 成員可以是在編譯時(shí)或運(yùn)行時(shí)存在的字段。 上一個(gè)：?* Node = null是結(jié)構(gòu)字段的一個(gè)示例，該字段在編譯時(shí)存在，但其默認(rèn)值為null。 那瘋狂的*前綴呢?
在Zig中，* Node表示類似于C / C ++的指向Node類型對(duì)象的指針。但是，由于Zig除非明確允許，否則不允許指針為null，因此必須添加?。指示指針可以為空。
節(jié)點(diǎn)本身被設(shè)置為周圍匿名結(jié)構(gòu)的字段。 但是，由于將其定義為const，因此僅在編譯時(shí)存在。 如果在運(yùn)行時(shí)檢查L(zhǎng)inkedList結(jié)構(gòu)的內(nèi)存，則找不到與Node對(duì)應(yīng)的區(qū)域。
另外請(qǐng)記住，雖然您可以在編譯時(shí)將類型用作任何其他對(duì)象，但它們?cè)谶\(yùn)行時(shí)在Zig中并不存在。 因此，基本上我們?cè)谶@里所做的就是創(chuàng)建帶有嵌套類型的結(jié)構(gòu)。
讓我使用Loris Cro的示例之一進(jìn)行更好的解釋。首先，他創(chuàng)建一個(gè)包含點(diǎn)的鏈表，并將其分配給僅在編譯時(shí)存在的名為PointList的變量：
- const PointList = LinkedList(Point);
然后，我們可以使用此新創(chuàng)建的類型實(shí)例化一個(gè)空列表。
- var my_list = PointList{};
我們不需要為first，last和len指定任何初始值，因?yàn)樗鼈兙哂心J(rèn)值。
在這里，我們使用嵌套類型創(chuàng)建一個(gè)Node對(duì)象來(lái)保存我們的點(diǎn)數(shù)據(jù)：
- const p = Point{ .x = 0, .y = 2, .z = 8 };
- var node = PointList.Node{ .data = p };
- my_list.first = &node;
- my_list.last = &node;
- my_list.len = 1;
在Zig中模擬接口
盡管Zig沒有類或面向?qū)ο笳Z(yǔ)言之類的接口的關(guān)鍵字，但我們?nèi)匀豢梢詷?gòu)建自己的運(yùn)行時(shí)多態(tài)系統(tǒng)，類似于C程序員多年來(lái)所做的那樣。
您只需使用函數(shù)指針定義結(jié)構(gòu)即可。在Unix內(nèi)核中，您看到了類似的操作，可以對(duì)任何文件描述符進(jìn)行通用處理，無(wú)論它們是文件，套接字還是管道。
- typedef struct _File {
- void (*write)(void *fd, char *data);
- void (*read)(void *fd, char *buffer, int size);
- void (*close)(void *fd);
- }
- File;
這并不完全是它的定義方式。 我只是從內(nèi)存中做到這一點(diǎn)。 這允許我們做的是為文件，套接字和管道提供不同的打開功能。 但是，由于它們都給了我們File結(jié)構(gòu)，因此其他函數(shù)可以使用其包含的這些函數(shù)指針對(duì)此進(jìn)行操作，從而抽象出底層結(jié)構(gòu)的差異。
在Zig中，我們使用Nathan Michaels在此處更詳細(xì)描述的類似方法。 Zig比C提供了更好的功能，因此您會(huì)看到Zig在創(chuàng)建通用迭代器，分配器，讀取器，寫入器以及在Zig中進(jìn)行更多操作時(shí)使用了更多功能。
有人可能會(huì)問(wèn)，為什么不將這類內(nèi)容納入語(yǔ)言呢?如果您曾經(jīng)使用過(guò)Lua，那么您將了解一些優(yōu)點(diǎn)，而不是給您構(gòu)造塊以創(chuàng)建面向?qū)ο蟮南到y(tǒng)，而不是對(duì)其進(jìn)行硬接線。
使用Zig，您可以構(gòu)建C ++風(fēng)格的面向?qū)ο蟮南到y(tǒng)，類似于Go甚至是類似于諸如Objective-C之類的更動(dòng)態(tài)語(yǔ)言的面向?qū)ο缶幊獭?/p>
這種自行開發(fā)的方法可能非常有效。我們已經(jīng)看到LISP程序員使用它來(lái)在LISP中構(gòu)建面向?qū)ο蟮木幊滔到y(tǒng)，甚至創(chuàng)建類似于Julia的多調(diào)度系統(tǒng)。
當(dāng)前題目：Zig是碼農(nóng)們期待已久的C語(yǔ)言的替代品嗎？
分享路徑：http://www.5511xx.com/article/cceisso.html
