手机版
你好,游客 登录 注册
背景:
阅读新闻

发布至今18年,为什么SQLite一定要用C语言来开发?

[日期:2018-09-04] 来源:infoq.com  作者:SQLite ,译者 无明 [字体: ]

C语言是最好的

SQLite在2000年5月29日发布,并一直使用C语言实现。C语言一直是实现SQLite这类软件库的最佳语言,目前还没有计划使用其他编程语言重新开发SQLite。

C语言是实现SQLite的最佳语言,原因有四:性能、兼容性、低依赖性、稳定性。

性能

像SQLite这样低级库速度必须要快。确实,SQLite的速度很快,甚至比文件系统要快上35%。

C语言非常适合用来开发这种对速度有要求的代码。C语言有时被称为“可移植的汇编语言”。它让开发人员能够尽可能地靠近底层硬件,同时仍然可以保持跨平台可移植性。

有些语言声称自己“与C语言一样快”,但却没有一门语言敢声称在作为通用目的编程时比C语言快,因为真的没有。

兼容性

几乎所有系统都能够调用用C语言编写的库,但不一定都能调用使用其他语言实现的库。

例如,使用Java开发的Android应用程序也能调用SQLite(通过适配器)。如果使用Java开发SQLite,那么对Android来说可能会更加方便,因为接口会更简单。但是,在iPhone上,应用程序是用Objective-C或Swift开发的,它们都不能调用使用Java编写的库。因此,如果使用Java开发,SQLite将无法在iPhone上使用。

低依赖性

使用C语言开发的库没有太多运行时依赖。SQLite的最低配置只依赖标准C库的以下几个例程:memcmp()、strcmp()、memcpy()、strlen()、memmove()、strncmp()、memset()。

对于更完整的版本,SQLite还使用了malloc()和free()之类的例程以及用于打开、读取、写入和关闭文件的操作系统接口。但即便如此,依赖项的数量仍然非常少。相比之下,其他“现代”语言通常需要加载数兆字节带有成千上万个接口的运行时。

稳定性

C语言陈旧乏味,是一门众所周知且易于理解的语言。这正好契合了SQLite的要求。如果没有C语言这样的语言,开发一个小型、快速、可靠的数据库引擎是很困难的。

为什么SQLite不使用面向对象语言来开发?

一些程序员无法想象怎么可以使用非“面向对象”的语言来开发像SQLite这样的复杂系统。那么为什么SQLite没有用C++或Java来开发?

  1. 使用C++或Java编写的库通常只能由以相同语言开发的应用程序使用。使用Haskell或Java开发的应用程序很难调用C++库。反过来,用C语言编写的库可以在其他编程语言中调用。
  2. 面向对象是一种设计模式,而不是一种编程语言。你可以使用任何语言(包括汇编语言)实现面向对象编程,只是某些语言(例如C++或Java)让面向对象变成变得更容易而已。但你仍然可以用像C这样的语言进行面向对象编程。
  3. 面向对象并不是唯一有效的设计模式。很多程序员被教导使用纯粹的面向对象方式进行思考。对象通常是分解问题的好方法,但对象不是唯一的方法,而且不一定是分解问题的最佳方法。有时候,过程式的代码更容易编写,更易于维护和理解,并且比面向对象的代码运行地更快。
  4. 最初在开发SQLite时,Java还只是一门年轻而不成熟的语言。C++比较成熟一些,但正在经历成长的痛苦时期,当时很难找到两种能够以相同方式工作的C++编译器。所以,在当时C语言绝对是一个更好的选择。现在这种情况没有那么明显,但现在重新开发SQLite几乎没有任何好处。

为什么SQLite不使用“安全”的编程语言来开发?

最近人们对像Rust或Go这样的“安全”编程语言很感兴趣。在使用这些编程语言时,不太可能或至少很难犯下常见的编程错误,如内存泄漏或数组溢出。因此,经常会有人问为什么SQLite不使用“安全”的语言来开发。

  1. 在SQLite出现后的头10年中,所谓的安全的编程语言并不存在。SQLite可以使用Go语言或Rust重新开发,但这样做可能会引入更多的错误,并且也可能导致代码运行得更慢。
  2. 安全的编程语言解决了容易出现的问题:内存泄漏、use-after-free错误、数组溢出等。安全语言在解决SQL计算结果这个问题上,不会比普通的C语言代码提供更多的帮助。
  3. 安全语言通常声称自己有助于防止安全漏洞。话是没错,但SQLite并不是一个对安全特别敏感的库。如果应用程序运行了不受信任且未经验证的SQL,那么它已经存在更大的安全问题(SQL注入),没有哪一门“安全”的语言可以修复这个问题。确实,应用程序有时会从不受信任的来源导入SQLite二进制数据库文件,这样可能会带来潜在的威胁。但是,SQLite中的这种代码路径是很有限的,并且经过了良好的测试。SQLite还为希望读取不受信任数据库的应用程序提供了预验证例程,帮助应用程序检测潜在的威胁。
  4. 一些“安全”语言(例如Go语言)不喜欢使用assert()。但是使用assert()是保持SQLite可维护性的重要前提。
  5. 安全语言会插入额外的分支逻辑来执行其他一些操作,比如验证数组访问是否越界。而在正确的代码中,永远不会使用这些分支逻辑。这也意味着机器代码不会100%被测试到,而这却恰好是SQLite质量策略的重要组成部分。
  6. 安全语言通常希望在遇到内存不足(OOM)时终止运行。SQLite却被设计成能够从OOM中正常恢复。目前还不知道该如何在安全语言中实现这一特性。
  7. 现在所有的安全语言都是新生儿。SQLite的开发人员对计算机语言研究人员努力开发更容易、更安全的编程语言表示赞赏,我们鼓励他们继续努力下去。但在实现SQLite时,我们对陈旧乏味的C语言更感兴趣。

SQLite可能有一天会使用Rust重新开发。由于Go语言讨厌assert(),因此不太可能使用Go语言。但使用Rust也只是一种可能性。如果要使用Rust重新开发SQLite,需要满足一些先决条件:

  1. Rust需要变得更成熟,减慢演化速度,并且要变得更加陈旧乏味。
  2. Rust需要证明它可以用于构建能够在所有其他编程语言中调用的通用库。
  3. Rust需要证明它可以生成适用于嵌入式设备的代码,包括缺少操作系统的设备。
  4. Rust需要提供可以对二进制文件进行100%分支覆盖测试的工具。
  5. Rust需要提供一种能够从OOM错误中优雅恢复的机制。
  6. Rust需要证明它可以完成C语言在SQLite中所做的各种工作而不会降低性能。

英文原文:https://sqlite.org/whyc.html

Linux公社的RSS地址:https://www.linuxidc.com/rssFeed.aspx

本文永久更新链接地址https://www.linuxidc.com/Linux/2018-09/153860.htm

linux
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款