Gnu的C函数库

C 函式库:

(作者: 谢东翰)



A.   简介:

由于我们的程序中经常需要处理许多特定的动作，例如搜寻与排序、行程管理与通讯、档案格式转换、甚至绘图 .... 等等，而这些动作可能很不单纯，若每个动作细节都从要从头开始设计撰写的话，往往相当耗时耗力，而且很不经济。因此，程序设计师便着手将程序中常常需要的一些动作分类、整理，将它们写成一个个「函式库」，供程序开发者使用，而不必每次都重新发明轮子。因此，「函式库」可以说是程序开发工作中重要的宝藏，也许一般使用者并不觉得，但它们也是支持系统中所有应用程序正常运作的背后无名英雄。函式库的种类相当繁多，而且用途各自不同。

以 UNIX 系统而言，其最底层，而且也最重要的函式库，莫过于 C 函式库了。由于 C 语言可以说是 UNIX 操作系统的母语，早年当 UNIX 还在 AT&T 草创之初，为了让整个系统在各硬件平台间的移植工作更为容易，同时尽可能地保持系统的执行效能，才因应而开发了此程序语言，并将整个作业系统以此语言重新改写。目前据估计在一般的 UNIX 系统中约 90% 以上是由 C 或C++ 程序代码写成的，其中包括大部分的系统核心、系统函式库、大部分的系统工具、窗口系统等等皆是。

标准的 C 语言中并不包含如资料的输出入、内存管理、及其它进阶的系统服务 ....等其它程序语言中常见的组件。相反的，C 语言将这些组件留给操作系统来实作，而当我们的程序需要使用这些组件时，必须经由操作系统提供的 C 函式库 (libc) 来取得这些服务。因此，C 函式库可以说是除了系统核心以外，所有应用程序赖以执行的基底环境，同时它也是应用程序与系统核心沟通的桥梁。

一般而言，一个标准的 C 函式库会包含两类的函式群，一为与核心沟通的系统呼叫窗口，二为一般常用的函式对象。

「系统呼叫」可以说是应用程序可以由操作系统中取得的最低阶操作，是由系统核心直接提供服务，它提供一组系统呼叫接口供应用程序使用，而系统呼叫的入口处就在 C 函式库的某些函式中。因此，应用程序藉由连结 C函式库的这些系统呼叫窗口，进而与系统核心连系。

而一般常用的函式对象则包括字元、字符串处理、数学函式库、搜寻排序算法、标准输出入 .... 等等。不论是系统呼叫窗口或是常用的函式对象，为了达到程序在各 UNIX 平台的可移植性，这中间必须要有一定的规格存在，供系统开发者依循。这些规格日后演生出许多不同的标准，详见后述。

除此之外，函式库与应用程序间的连结形态可分为「静态函式库 (static library)」与「可分享函式库 (shared library)」两种。前者只是单纯将所有的函式与对象打包成一个函式库档，而使用此函式库的程序在编译时，必须将其用到的所有函式与对象的程序代码自函式库档抽出来，然后与程序本身的程序代码连结在一起，如此才能形成一个完整的可执行档。

然而，由于函式库中内含的函式与对象在许多程序中都会用到，如果每个程序都必须连结一份所需的函式与对象时，显然相当占空间。因此，才有后者的「可分享函式库」的出现。

在支持分享式函式库的系统环境下，程序编译时不需要将所需的函式与对象静态连结进来，而是等到程序要执行时，才由操作系统自动做连结的动作。由于很多程序都会用到相同的函式对象，故事实上操作系统在执行时只会在内存中保存一份函式对象而已，当有程序在执行中要用到它时，就自动跳过来执行，执行完毕后再跳回原程序中。因此，同一份函式对象可以让所有的程序分享，这不尽可节省硬盘的储存空间，同时也节省执行时整体的内存使用量。

所有的 UNIX 系统都提供了它们的 C 函式库，而在新近设计的 UNIX 系统中，多半会有分享式函式库的支持，但其形态可能各异，支持承度也有所不同。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有