C语言入门书籍推荐
05年上大一的时候开始学C语言,当时用的教材是谭浩强版的《C语言程序设计》,[狗头],这本书真是应试教育的典范,填鸭式的内容,夹杂着各种错误,本该重点描述的地方浅尝辄止,各种吐槽点……
工作这么多年,到目前为止读了不少C相关的书籍。在走了很多弯路以后,个人认为一个正确的C语言的学习的路径应该为,
- 在学习编程语言之前,建议先了解什么是计算机,可以观看《Crash Course Computer Science》;
- 安装一个linux系统,现在已经越来越方便了,比如,可以在win11上安装wsl2和ubuntu,学习一些linux的基础命令;
- 了解操作系统的基本原理,什么是进程、线程,编译、链接的基本原理,应用程序是如何运行的;
- 学习gcc,gdb的基本使用命令(初期最好不要使用集成开发环境,例如visual studio,clion等强大的IDE去编写程序,建议直接命令行),结合预编译、编译、汇编、链接等指令去更深入的了解程序运行的原理,利用gdb去调试代码;
- 学习一门基础语言,如果是第一门编程语言,那肯定是C,它应用广泛,操作系统(系统编程)、驱动、编译器开发、网络编程(socket)、音视频、游戏、GUI(部分组件)、嵌入式等等都是它的擅长领域,在编程语言中一直排名前3。它足够经典及精炼,执行效率高,占用内存少,可以“直接”和计算机硬件打交道,能更深一步的了解计算机的软硬件运行原理;
- 学习cmake的基础语法及命令,因为目前大部分的开源C/C++代码都支持cmake编译;
- 在掌握了一门基础语言后,学习对应的数据结构、算法、设计模式等。在这个阶段多去读一些开源的优秀源码,从小项目到大项目,学以致用,去学习优秀的大牛们是如何设计软件,如何利用简单的c语言去编写出优雅的代码;
- 最后,在自己感兴趣的特定领域,例如网络编程,去学习一些已有的广泛使用的第三方库的使用。然后,去写一些现实中实际可以用的程序;
下面是我认为比较好的一些C语言书籍的推荐:
该书由计算机科学家Brian Kernighan和C语言之父Dennis Ritchie合著,是第一部介绍C语言编程方法的书籍。它因作者名字的缩写被简称为K&R;或是因封面颜色,也被称为白皮书。在C语言的发展和普及过程中起到了非常重要的作用,被视为是C语言的业界标准规范,而且至今仍然广泛使用。它被公认为计算机技术著作的典范,以清晰简洁的文字讲述而著称。书中用\”hello world\”为实例开始讲解程序设计,成为程序设计语言图书的传统。
相比于K&R,这本书更贴近于实际的应用,也更“现代”,适合进阶使用,所讲述的知识点都是干货,几乎没有废话。本书主要目的就是通过一种“现代方法”来介绍C语言,书中强调标准C,强调软件工程。第2版修订版中不仅有C99中的新特性,还与时俱进地增加了C11和C18中的内容。本书分为C语言的基础特性、C语言的高级特性、C语言标准库和参考资料4个部分。每章末尾的“问与答”部分给出一系列与该章内容相关的问题及答案,带着读者去思考,作者的水平真的是很高。
当你有一定的编程基础后,建议开始读《深入理解计算机系统》这本书,多读几遍,这本书“很硬”,每次读完的感受应该都不同。本书从程序员的视角详细阐述计算机系统的本质概念,并展示这些概念如何实实在在地影响应用程序的正确性、性能和实用性。全书共12章,主要内容包括信息的表示和处理、程序的机器级表示、处理器体系结构、优化程序性能、存储器层次结构、链接、异常控制流、虚拟存储器、系统级I/O、网络编程、并发编程等。书中提供大量的例子和练习,并给出部分答案,有助于读者加深对正文所述概念和知识的理解。
本书的最大优点是为程序员描述计算机系统的实现细节,帮助其在大脑中构造一个层次型的计算机系统,从最底层的数据在内存中的表示到流水线指令的构成,到虚拟存储器,到编译系统,到动态加载库,到最后的用户态应用。通过掌握程序是如何映射到系统上,以及程序是如何执行的,读者能够更好地理解程序的行为为什么是这样的,以及效率低下是如何造成的。
如下是kitware官网的介绍,cmake现在确实已经成为了c/c++软件系统的常用构建工具,
CMake: A Powerful Software Build System CMake is the de-facto standard for building C++ code, with over 2 million downloads a month. It’s a powerful, comprehensive solution for managing the software build process. Get everything you need to successfully leverage CMake by visiting our resources section.
cmake经过多年的发展,已经变得非常复杂。如果光读官网的文档,应该很少有人能读的下去。目前关于cmake的书籍很少,下面这本书是新出的,对cmake的方方面面都做了介绍,非常适合cmake的新人,如果你想深入了解cmake的构建系统,建议阅读本书,github有本书的翻译版本,地址为https://github.com/xiaoweiChen/Modern-CMake-for-Cpp,但是还是建议大家读英文原版。
当掌握了C语言本身后,如果你是从事linux/unix相关领域软件的开发,我建议你一定要读下面的两本书(应该是3本,因为第一本是上下两册),虽然都很厚,但是如果认真读完,融会贯通,收获会非常大。建议先读第一本《Linux/UNIX系统编程手册》,如果有精力可以再精读《UNIX环境高级编程》,两本书可以互补。
本书是介绍linux与unix编程接口的权威著作,主要讲解了高效读写文件,对信号、时钟和定时器的运用,创建进程、执行程序,编写安全的应用程序,运用posix线程技术编写多线程程序,创建和使用共享库,运用管道、消息队列、共享内存和信号量技术来进行进程间通信,以及运用套接字api编写网络应用等内容。 在汇聚大批 linux专有特性(epoll、inotify、/proc)的同时,还特意强化了对unix标准(posix、sus)的论述,彻底达到了“鱼与熊掌,二者得兼”的效果,这也堪称本书的最大亮点。
很多人都知道APUE这本书,在本书第1版出版后的十几年中,UNIX行业已经有了巨大的变化,特别是影响UNIX编程接口的有关标准变化很大。本书在保持了前一版风格的基础上,根据最新的标准对内容进行了修订和增补,反映了最新的技术发展。书中除了介绍UNIX文件和目录、标准I/O库、系统数据文件和信息、进程环境、进程控制、进程关系、信号、线程、线程控制、守护进程、各种I/O、进程间通信、网络IPC、伪终端等方面的内容,还在此基础上介绍了多个应用示例,包括如何创建数据库函数库以及如何与网络打印机通信等。
如果是从事网络编程的相关领域,建议先读《TCP/IP详解 卷1:协议》,
本书是一本完整而详细的TCP/IP协议指南。描述了属于每一层的各个协议以及它们如何在不同操作系统中运行。作者W.Richard Stevens是大牛,书中对各层协议进行了详解,同时结合tcpdump的抓包结果对协议进行了深入的分析。
本书主要结合TCP/IP协议介绍unix socket 相关api,本书第1、2版由Richard Stevens编写,第3版,由世界著名网络专家Bill Fenner和Andrew M. Rudoff执笔,根据近几年网络技术的发展,对上一版进行全面修订,增添了IPv6的更新过的信息、SCTP协议和密钥管理套接口的内容,删除了X/Open传输接口的内容。
Rust到底值不值得学–Rust对比、特色和理念
其实我一直弄不明白一点,那就是计算机技术的发展,是让这个世界变得简单了,还是变得更复杂了。当然这只是一个玩笑,可别把这个问题当真。
然而对于IT从业者来说,这可不是一个玩笑。几乎每一次的技术发展,都让这个生态变得更为复杂。“英年早秃”已经成为一种很普遍的现象。
Rust是近两年呼声比较高的一种新型开发语言。市场占有量并不大,但增长速度极为迅猛。有人统计过,在计算机行业,平均每33.5天就有一种所谓的新型开发语言面世,这还不包括很多企业内部、项目内部的内置简易流程工具。然而大浪淘沙,如今仍然占据着市场地位的,不过仍然是耳熟能详的有限几种。作为新来的搅局者,Rust到底值不值得学习并且在工作中应用呢?
先说结论,这里粗略的把开发者分为初学者、小有经验的常规工程师和资深开发者三类。对于初学者,Rust具有比较陡峭的学习曲线,虽然学习Rust能训练良好的编程习惯,从长远看对提高学习者的开发素养极具价值。但短期的大量付出很容易让初学者心力交瘁。并且尽管官方文档并不欠缺,但学习资料对于初学者来讲仍然是远远不够的。所以比较而言,得不偿失。因此建议初学者仍然由久经验证的语言入门加入软件开发的大家庭。比如说C/Java/Python/Js都是很好的入门选择。对于有一定经验的常规工程师,他们已经有了一段时间的开发工作实践,对于软件开发的现状、发展都已经形成了自己的世界观。如果感觉并不很喜欢这个行业,希望将来转行管理岗位或者产品岗位。那当前应当做的更多是倾向业务领域,了解业务和技术的衔接和互动,完全不需要学习Rust。而如果醉心于技术,并从中获得了自己的乐趣,希望逐步提高自己的技术水平。那么Rust会是一个很好的桥梁,哪怕仅仅学习Rust而并不将其应用于工作,也能让开发者从中获取大量的有益习惯和软件底层经验,从而形成自己良好的代码风格。对于资深工程师,即便并不从而底层系统级的开发工作,Rust也是一门很优秀的语言。它能弥补当前多种开发语言的不足,形成良好的开发哲学和思想导向,帮助开发者交付高质量的软件产品。因此,及早学习并应用Rust非常有价值。
为了说明这个结论,下面从多个角度,采用同传统语言对比的方式来说一说我对Rust的理解。
这几年有不少有影响的语言出现,但大多数都只是关键字或者小范围的语法创新,随后可能会有大量的特色库函数来丰富语言的功能。一个有经验的开发者,可能翻两天资料,就能快速的掌握。而Rust极具自身语言特点,是一种完全的创新,而不是简单的语法替换。简单的熟悉几个关键字和判断、循环等语法,远不足以掌握这门语言。为了证明这一点,下面用Rust的“所有权”(Ownership)机制和“遮蔽”(Shadowing)来举例说明。
以C++为例,请看下面这段代码:
编译执行后,程序输出:
代码再简单不过,首先声明、赋值一个字符串变量s1,然后把变量s1赋值给变量s2,最后输出两者的值。
对应的,我们看一个Rust的版本:
除了细小的语法差异,看上去跟C++的版本没有什么不同。然而在Rust中,这段代码连编译都无法通过,得益于rustc编译程序详细的输出,我们能看到很细致的错误提示:
这个编译错误是指,上面代码中,当变量s1赋值给s2之后,s1变量名所指向的内存所有权,被“转移”(move)到了s2变量名拥有之下。而从此之后,s1变量名就无效了,不再指向任何一块内存。除非重新声明并为s1赋值(Rust中称为Shadow,\”遮蔽\”原有的s1),s1不能再被使用。所有权机制可以有效的防止内存泄露所导致的程序Bug,是Rust内存管理的核心理念。上面提到的所有权“转移”是所有权管理的重要特征之一。
“遮蔽”也是一个有趣的概念,Rust的处理方式跟很多我们熟悉的语言不同。请看下面C语言代码:
这又是一段很基本的代码。首先声明、赋值一个整数变量x,接着把x的值加1,再赋值回变量x。这是各种开发语言中都常见的用法。编译执行的输出结果为x=6。来看看Rust的版本:
很不幸,这段代码同样无法编译通过,错误是:
rustc这种“图示”型的输出信息让你排查错误更加方便。错误的原因,在Rust中,默认所有变量都是只读类型的,除非在变量声明的时候就注明为可变类型\”mut\”。因此两次对于一个只读变量赋值导致编译错误。解决的办法或者注明变量为可读写,这样同C语言的版本具有完全相同的意义:
或者用我们上面提到过的“遮蔽”机制:
注意上面x=x+1,这一行的开始我们再次使用let关键字,这表示再次声明了变量x。与大多数语言不允许重复声明变量不同,这个x变量,跟第一次声明的变量x同名,并对其做出了“遮蔽”。之后除非再次遮蔽变量x,那起作用的,都将是本次新声明的x。
通过这两个例子,可以看出Rust是从理念上做出了大量创新的一种语言。如果只是像学习其它语言一样只是对比学习语法和关键字,无法真正掌握这门语言。这些融汇在语言中的理念,才是Rust最宝贵的地方。注意在这里“理念”可不是什么大而化之的套话,而是实际操作中很重要的原则。很多语言的设计初衷是“简化”,在Rust中当然也有很多简化的地方,就像直接使用“let”关键字声明一个变量,而变量的类型可以通过赋值的操作从而推导出变量的类型。比如变量超出作用域,也会被自动的回收。但Rust中也大量的存在了“复杂化”的操作,比如上面举例的所有权机制,再比如使用可读写变量需要额外标注“mut”。这些“复杂化”的部分,都基于“尽量在程序开发的早期,就将可能会出现问题的部分暴露出来,从而在设计中和编译时就解决掉。”这样一个理念。
承接自Rust的拥有权机制。引用和借用在Rust中也迥异于大量的传统语言。引用类似C语言中的指针,指向一块已经存在的数据:
上例中,y就是对变量x的引用,并且没有标注mut,所以是只读引用。写法跟C语言中获取指针的方式类似,就是一个&符号。y此时具有了变量x的一些权限,所以也称为“借用”,本例中因为只借用了读的功能,没有借用写的功能,所以称“一些”。当然也可以借用写的功能,我们后面会再举例。借用看起来跟引用是一回事,但“借用”这个词更主要对应的是上面所说的所有权“转移”的概念,转移之后,原来的变量就无效了。而借用之后,原来的变量还有效,或者部分有效,比如只被借用了写权限。
在函数参数中,使用引用的方式,从而让函数临时性的获得数据的访问权,也是典型的借用。事实上这种方式才是最常用到借用的地方:
先别管我们使用到的令人困惑的关键字和函数名,那些进入到系统学习之后都不算什么。在函数sum_vec的参数中,我们就使用了借用。顺便,我们还见识了Rust中函数的嵌套写法,当然现在新兴的语言,包括C++11之后的版本,都已经支持这种写法,这在函数式(Functional programming paradigm,注意不是函数化Functionalization)编程中是很重要的支持。
引用和借用的概念,同C/C++语言中所使用的都是很类似的,尽管名称不同。主要的区别来自于对引用的管理理念,Rust对引用的管理规则如下:
- 对于一块内存,同时只能有一个可写引用存在
- 对于一块内存,同时可以有多个只读引用存在
- 对于一块内存,在有一个可写引用存在的时候,不能有其它引用存在,无论只读或者可写。
- 引用的原始对象必须在引用存在的生命期一直有效
比如:
上面代码会产生编译错误,因为y已经是可写的引用,而同时再存在一个可写的引用z,违反了Rust对引用的管理规则。如果把z变量这一行和后面显示z的部分去掉呢?去掉之后是可以编译通过的,但仍然要注意,y此时是可写的指针,“借用”了x的写权限。所以x此时只有读的权限,不能再对x进行赋值。因为它已经被“借用走”(Borrowed)了。
这些复杂的规则,看起来就跟前面见过的所有权转移一样,似乎极大的限制了程序员的自由度。但这些都是在强迫你,让你成为一个更优秀的程序员,产生出更高质量的代码,将Bug消灭在萌芽期。
通常一个变量的生命期就是它的作用域。但在引用和借用出现后,这个问题变得复杂了。熟悉C语言的程序员都碰到过数据失效了,而指针依然存在的情况,俗称“悬挂指针”。Java为了解决这个问题干脆取消了指针,并且最终以引用计数器做为了内存管理的主要模式。
这种情况出现最多的场景,是在某个函数中使用了变量或者申请了内存,并将其引用作为返回值传递到了调用者的时候。比如这段C语言代码:
c变量位于栈上,是一个局部变量,当函数返回指针的时候,指针在这个函数的调用者中依然存在,但c变量已经被回收了。在新版本的编译器中,这种情况也会被警告,但可以编译成功。而在Rust中,这种情况是不允许编译通过的,比如下面类似代码:
编译的时候会报错“result变量没有足够长的生命期”:
如果仅仅是这样断然的禁止返回悬挂引用也就“不过如此”了。事实上更复杂的问题来自于,如果数据源来自于函数的参数,参数本身就是引用的情况。比如请看下面的Rust代码:
上面这个函数接受两个字符串的引用(实际是Slice,本文不是教学,请先忽略语法问题),比较其长度,将长的那个字符串作为结果返回调用者。顺便,这种返回值的方式一定让你印象深刻。虽然示例简单,但不可否认,这种需求是很正当的。大量的应用场景都需要函数独立于外,处理固定的内存数据,进入和返回的,都只是指向内存的指针。当然,尽管合理,上面的代码是无法编译通过的,报错是“丢失生命期指定”:
Rust引入了生命期的概念,从而保证返回值,同给定的参数,具有相同的生命期。这即保证了程序的灵活性,而又不造成内存的泄露,同时还不把维护内存安全的责任,完全推给不可靠的人为因素。
上面的代码,添加了生命期指定。在函数名之后首先声明了生命期a,语法样式跟泛型的类型说明部分实际是一样的,都放在尖括号<>之中。生命期名称之前附加一个单引号\’。随后的两个引用参数x/y以及作为返回值的字符串引用,都直接在&符号之后标注了生命期\’a。这表示,这几个引用,具有相同的生命期。当然从这里的例子,x/y是调用的参数,是外面传递进来的,所以完整的含义应当是:返回的引用值,同参数x/y一样具有相同的生命期。因此从调用者的角度来看,当x/y指向的内存,超出作用域销毁之后,所获得的函数返回值,也同时被销毁。
有一个特殊的生命期\’static,用于代表rust中的全局量或者静态量,专门表示这种引用具有贯穿于整个程序运行时的生命期长度。比如Rust中通常用字面量赋值的字符串,实际都是\’static,因为这些字面量实际在程序编译的时候就放置到了数据区并一直存在贯穿程序始终:
通过前面的几个个例子,我们对Rust的编译器rustc有了一个初步概念。丰富、详尽的编译错误输出对于排查源码中的错误帮助很大。实际上远不止于此。Rust的编译器包含着Rust语言的另外一个核心思想,那就是,尽量在编译阶段就暴露出程序的设计错误,而不让这些错误带到生产环境从而付出昂贵的代价。这也是Rust学习曲线陡峭的原因之一,很多在其它语言中可以编译通过的代码,在Rust中都无法通过编译(排除语法错误之外)。这种更严格的编译时检查很容易让初学者手足无措。带来的优点也是显而易见的,除了刚才提过的不让程序Bug带入到生产环境之外,错误能在编译阶段就消除掉,无需在运行时进行更多不必要的错误检查,这也将大大的减少程序在运行时消耗。这个消耗包括编译所生成的代码体积和运行时检查所损耗的CPU资源两个方面。
比如Rust中有多种不同功能的智能指针,以常见的Box和Rc为例,前者提供基本的指针功能,后者提供类似Java语言一样,基于引用统计的自动垃圾回收机制。(请注意我们这里并不是做语言学习,所以请关注在Rust的设计理念上,先别在意具体的关键字和语法。)
如果在程序中使用Box指针的话,当变量x被赋值给变量y,所有权同时被转移,变量x就不再可用了,这个我们在开始的所有权介绍时就见到了:
与此规则对应的所有操作,在程序的编译器就可以做出检查,从而判断是否有错误存在。但毕竟我们也有其它的需求,比如我们希望同时有多个指针指向同一块存储区域。这时候就需要使用Rc指针。
但显然,使用Rc指针的时候,我们无法在编译过程中发现可能的错误。并且,Rc指针类似Java,当对一块内存的所有引用都失效之后,系统会释放这部分内存。而这个过程,都需要在程序执行的过程中,有对应的管理代码不停的工作,以保证跟踪内存的引用和内存的释放(垃圾回收)。这就产生了运行时开销。
为了对运行时开销能够更精确的掌控,Rust在语言层面增加了许多选择,这些选择在其它语言中本来是不需要的。但一个经验丰富的程序员,则能充分的利用这些不同的选择写出高品质的代码。比如Rc指针并不支持多线程,因为其中的引用计数器操作不是原子级的,所以Rust还提供了Arc用于多线程环境。当然,原子级的操作在运行时需要额外的开销。
与Rust语言的编译设计相映成趣的是Go,Go语言提供非常快速的编译过程,从而提供流畅的开发体验,让Go语言易于学习和使用。但Go的编译质量早就为人所诟病。当然更极端的例子是Python、Js等脚本型的语言,脚本语言完全无需编译。虽然执行效率方面这些年来随着电脑性能的提高已经不是严重问题,但大多错误几乎都只能通过代码的执行来发现。使得脚本语言在商业软件开发中占有率一直不高,更别说操作系统这一类的底层软件了。
总结一下这一部分,Rust提供高级语言所具有的一些特征,比如自动的运行时垃圾回收机制。但同时也提供并且倾向于开发人员通过精细的设计,在开发和程序编译过程中就完成内存的设计和管理,从而及早发现错误,降低运行时开销,提高最终的代码质量。
面向对象是现代开发语言的基本能力。但Rust只提供了有限的面向对象支持。我衷心的认为这是一件好事,我一直认为现在很多的程序员,往往为了面向对象而去面向对象开发。把原本很简单的事情做的过于复杂,使得代码量和运行开销高企不下,开发效率和执行效率完全失控。Linus Torvalds曾经在那场著名的辩论中直呼C++是“糟糕程序员的垃圾语言”,有兴趣的可以FQ去看原文:Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
在Rust中没有直接提供“类”(class)的概念,希望使用“对象”的程序员,可以直接在结构(struct)和枚举(enum)类型上附加函数方法,比如:
看上去跟Go处理对象的方法很像是吧,其实在面向对象方面Go语言的理念也是高举了“简化”的大旗。Rust也没有我们习惯了的构造函数和析构函数。上面代码中对Circle对象的初始化语句:
就是直接对成员变量的赋值。这是因为Rust推崇“明确化”(being explicit)的代码方式,也就是所有要执行的代码,应当清晰的在代码中体现出来。而不是隐藏在一些容易忘记、容易出错的构造函数之后。
与“简化对象”相反的,Rust对面向对象中“接口”(Java中的interface,或者C++中的多重继承)的概念做了发扬,贯穿在了Rust类型管理的方方面面。当然我这样说有点不算贴切,其实应当先忘记“接口”的概念,从头理解Rust中的“特质”(trait),因为特质和接口,只是在技术实现上有些类似,但在应用理念上还是很有区别的。本质上说,“特质”也是实现多个对象中,共性的方法,比如:
随后多个对象,都可以实现这个特质,从而都具有这个方法:
在Rust中,通过泛型的帮助,根据数据类型实现的不同特质,把类型分为不同的功能和用途。比如具有“Send”特质的类型,才可以安全的在多个线程间传递从而共享数据。比如具有“Copy”特质的类型,说明数据保存在栈(Stack)上,数据的复制(赋值给其它变量),不会产生所有权的转移(参考前面所有权的例子)。还有比如,刚才说过了Rust中没有析构函数,但如果有一些数据并没有被Rust所管理,需要自己去释放,则可以为自己定义的对象实现一个Drop特质,在其中的drop方法中释放自己申请的内存:
其它面向对象的编程特征,比如“泛型”,比如“重载”,同其它语言并没有很大的区别,这里不再额外介绍。这些相比较其它面向对象语言而言,并不算丰富的语法工具,是保留了面向对象开发模式最精华的部分。并不会对业务的描述造成什么障碍,反而会让建模工作更为简洁、务实,尽可能不造成代码上的晦涩和运行时的低效。
早期出现的开发语言,比如C,比如Java,本身并没有附加官方的管理工具。比如包管理、测试管理、编译管理。在语言的发展过程中,因为开发工作的需求,往往会出现多个有影响的工具。在C/C++方面,常见的编译管理工具有Makefile/CMake/AutoMake等,包管理工具,往往同系统包管理工具结合在一起,常见的有APT/YUM/Aptitude/Dnf/HomeBrew。Java的情况也很类似。新近风靡的语言,比如Python,Pip工具占了大部分市场。Nodejs则是NPM用户最多。Go语言的同名管理工具就更不用说了。这些现象,跟语言本身的官方支持密不可分。Rust也由官方直接发布Cargo工具,功能涵盖版本升级、项目管理、包管理、测试管理、编译管理等多方面。大多数初学者的Rust之旅,就是由执行cargo new helloworld开始的。开发语言的综合管理工具,对于构建大型的软件项目必不可少。相信在cargo的帮助下,让学习者快速的学以致用,把一些项目迁移至Rust能轻松不少。
一门语言能否被大量用户支持,与语言所提供的扩展库功能密不可分。我就见到不少程序员学习Python的原因,就是因为Python能够更好的支持PyTorch / TensorFlow等机器学习工具包。Rust通过Crate(可以翻译为扩展箱)机制支持自己的扩展包。而且通过内置的Cargo工具可以直接使用大量的官方预置扩展包和社区共享的扩展包。此外Rust还可以通过FFI接口(Foreign Function Interface)直接调用其它语言编写的函数库或者共享Rust函数给其它语言调用。比如我们在Rust中调用c++写的snappy压缩、解压功能包。Snappy官方网站为:https://google.github.io/snappy/,在macOS下安装Snappy包可以使用命令:brew install snappy。
因为使用了libc扩展库,需要在Cargo.toml中设置库依赖:
编译的时候,rustc会自动链接libc库和宏定义指明的snappy压缩解压库。
把Rust中定义的函数,共享给c语言调用也很类似,请看Rust代码:
上面的代码,需要设置Cargo.toml文件的lib参数:
从而让rustc将项目编译为.dylib动态链接库文件(macOS)或者.so动态链接库文件(Linux)。对应的C语言代码:
C代码编译的时候,记着使用-l参数链接rust生成的动态链接库。综上,迁移至Rust完全不用担心扩展库的限制,也完全不用担心同现有软件资源之间的互动、共享。可以从一个小的项目作为切入点,边学边用,在享受Rust安全可靠的同时,逐渐达成软件架构的迁移。
现在流行的开发语言很多,但能够进行操作系统底层开发的选择项并没有几个。除了传统的C、新近的Go,Rust是另一个不错的选择。做到这一点,除了Rust是真正的二进制编译之外,Rust还具有非常小并且可控的“脚印”(footprint)。这代表Rust可以做到完全没有自己的运行时库支持下运行。比如官方文档中提供的一个例子:
其中#![no_std]宏代码就表示本代码编译时不使用rust标准库。想要真正从头编写一个操作系统,这个话题还是比较大,有兴趣的可以参考一下这个博客:https://os.phil-opp.com/作者Philipp Oppermann循序渐进的演示用Rust在没有标准库甚至没有libc库的支持下从头开始编写一个操作系统,该博客提供了一个学习性的实现。
作为新兴的开发语言,Rust在函数式编程、网络编程、多线程、消息同步、锁、测试代码、异常处理等方面都有不俗表现。但本文不是Rust教学,所以这里不再介绍。建议在学习Rust的过程中,根据所选教程的组织结构来逐步了解。
企业应用中,Web框架和ORM是最常用到的组件,但这应当说是Rust当前的一个短板。因为毕竟Rust是一个新兴的生态系统,尽管选择很多,但尚没有重量级的选手出现。在性能和规模化的应用方面还有待市场验证。但Rust本身对内存、性能的精细管理,让我们可以对项目的总体性能保持信心。Actix-web、hyper的web框架,以及Diesel作为ORM是比较常见的组合。
Rust首先包含了长期软件工程中对于高频Bug的经验总结,从而开创性的提出了大量的全新编程理念。不同于很多新式语言给予开发者更多的便利和自由,Rust更苛刻的对待程序员的开发工作……尽管在易用方面Rust也下了不少的功夫,但相对于繁复的规则,这些努力很容易被忽视。而这些“成长的代价”保证了更高品质的开发输出。
比如自2004年以来,微软安全响应中心(MSRC)已对所有报告过的微软安全漏洞进行了分类。根据他们提供的数据,所有微软年度补丁中约有 70%是针对内存安全漏洞的修复程序。恐怕没有人再继续做延伸统计,比如这些安全漏洞造成了多少的经济损失。所以甚至已有传闻微软正在探索使用Rust编程语言作为 C、C++和其他语言的替代方案,以此来改善应用程序的安全状况。
Rust并不适合初学者,只有经历过大量实践磨炼,甚至被安全漏洞痛苦折磨的资深开发者,才能更理解Rust的价值。
自由还是安全,终要有所取舍。
本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com
文章为作者独立观点不代本网立场,未经允许不得转载。