数据缓冲区是用户前端用来存储、操纵数据的对象。在每一个DataWindow对象中有4个二维表作为数据缓冲区，用来存储查询到的数据。

开发具有高效性、简单性、可移植性和安全性的代码，C 程序设计语言定义了两个标准的内存管理函数：malloc() 和 free()。C 程序员经常使用那些函数在运行时分配缓冲区，以便在函数之间传递数据。然而在许多场合下，您无法预先确定缓冲区所需的实际大小，这对于构造复杂的 C 程序来说，可能会导致几个根本性的问题。在本文中，Xiaoming Zhang 倡导一种自我管理的抽象数据缓冲区。他概括地给出了抽象缓冲区的伪 C 代码实现，并详细介绍了采用这种机制的优点。

软件的规模和复杂性随时都在增长，从根本上影响了应用程序的体系结构。在许多场合下，将所有功能编码进软件的单个部分中是不切实际的。让独立的软件部分相互交互，比如以插件的形式，这样做的重要性正在变得越来越明显。要相对容易地实现这种交互，甚至是在不同厂商编写的软件部分之间，软件需要有定义良好的接口。使用诸如 C 这样的传统程序设计语言来编写满足这种需要的软件可能是一个挑战。

考虑到这种挑战，本文将研究 C 程序设计语言中的数据缓冲区接口，同时着眼于如何改进当前实践。尽管内存管理看起来可能无足轻重，但是恰当设计的接口能够产生高效、简单和可移植的代码 —— 这其中每个特性都需要进行内存管理才能实现。因而， 下一节将概略介绍程序员在采用传统数据缓冲区管理方案时所面对的各种问题。后面跟着要介绍的是 抽象数据缓冲区方案，并通过伪代码实现来进行说明，这种方案解决了许多问题；最后要介绍的是一些 代码片断，用以演示该解决方案的好处。

C 程序员经常使用动态分配的缓冲区（通过调用 malloc() / free() 函数）在函数之间传递数据。尽管该方法提供了灵活性，但它也带来了一些性能影响。首先，它要求在需要缓冲区块的任何地方进行额外的管理工作（分配和释放内存块）。如果分配和释放不能在相同的代码位置进行，那么确保在某个内存块不再需要时，释放一次（且仅释放一次）该内存块是很重要的；否则就可能导致内存泄露或代码崩溃。其次，必须预先确定缓冲区的大小才能分配该内存块。然而，您也许会发现，确定数据大小并不总是那么容易。开发人员经常采用最大数据尺寸的保守估计，而这样可能导致严重的内存资源浪费。

为避免由于多次释放而导致的可能的内存泄露和代码崩溃，好的编程实践要求您明确地预定义负责分配和释放缓冲区内存的程序部分。然而在实践中，定义职责会导致其他困难。在传统方案下，由于在创建缓冲区时必须指定大小，因此 数据提供者（它可能知道它所提供的数据的大小）是用来执行缓冲区分配操作的最佳搭档。另一方面，用于释放的最佳搭档可能是 数据使用者，因为它知道何时不再需要该数据。通常情况下，数据提供者和数据使用者是不相同的。

当数据提供者和数据使用者来自不同的软件提供商时，进行交互的各方可能采用不同的底层内存管理机制。例如，有些软件提供商可能选择自我管理的堆空间，而其他软件提供商则依赖底层操作系统（OS）来获得这样的功能。此外，不同的操作系统可能以不同的方式实现内存管理。例如，PalmOS 提供两种不同的内存资源：基于堆和基于数据库。一般来讲，不同的内存管理机制具有各自的优点和缺点，因此您可能不希望预先假定某种特定的机制。不同的首选项甚至可能导致相互冲突的代码编写习惯。

交互方之一定义用于数据交换的底层内存分配机制。另一方总是使用已公布的接口来分配或释放缓冲区，从而避免潜在的不一致。这种模型需要双方都坚持一个可能与软件基本功能无关的编程约定，而且在一般情况下，这个编程约定可能使代码更加不可重用。

驱动数据交换的那一方将负责管理操作 —— 当该方充当数据提供者时，这是一个相对适当的方案。 然而，当该方充当数据使用者时，事情就变得棘手了。为避免去发现数据大小，数据使用者可以分配一个任意大小的缓冲区。如果该数据缓冲区没有足够大，就必须对数据提供者发出多次调用。因此这种方法需要围绕该交互调用编写额外的循环代码，以备多次调用之需。

对于第三种选择，数据使用者将对管理操作负责。然而在这种情况下，如果另一方是数据提供者，数据使用者必须预先发出一次调用以发现缓冲区大小 —— 从而给另一方施加了更多的负担，即编写逻辑代码来提供关于缓冲区大小的信息，而这可能需要执行耗时的算法。而且，这种解决办法还可能引入严重的效率问题：假设函数 a() 从函数 b() 获得数据，后者反过来又在执行期间从函数 c() 获得数据。假设发现缓冲区大小和提供实际的数据都需要执行相同的算法。

为了从 b() 获得数据， a() 必须发出两次调用：一次用于确定缓冲区大小，另一次用于获得实际数据。对于向 a() 发出的每次调用， b() 都必须对 c() 发出两次调用。因此，当这个操作结束时， c() 中的算法代码可能已经执行了四次。原则上，该代码应该仅执行一次。

显而易见地，这三种解决办法全都存在局限性，因此传统缓冲区内存管理方法并不是适合编写大规模交互软件代码的机制。

除了上述困难之外，安全性也证明是传统方法存在的问题：传统缓冲区管理方案无法容易地防止恶意用户刻意改写数据缓冲区，从而导致程序异常。考虑到所有这一切，设计一个适当的数据缓冲区接口就势在必行！

首先在若干字符作为一个块传输比逐个发送字符耗费的时间少。其次如果你输入有误。就可以使用您的键盘更改功能来修正错误。并且最终按下回车，就可以发送正确的输入。

缓冲分为两类，完全缓冲和行缓冲。对于完全缓冲来说，缓冲区满时，缓冲区会被清空。此时缓冲区中的内容也会发往目的地。这种类型的缓冲通常出现在文件输入中。缓冲区的大小取决于系统。但512和4096字节的缓冲区大小比较常见，对于行缓冲来说，遇到一个换行字符时，缓冲区中的内容就会被清空。键盘输入是标准的行缓冲。因此按下回车，缓冲就会被清空。

从概念上讲，数据缓冲区在传统方案下是由两个操作创建的：数据缓冲区实体的创建和实际内存的分配。然而事实上，在实际数据变得可用之前，您不需要分配实际的内存 —— 即可以将两个操作分离开来。

最初可以使用内存块的一个空链表来创建一个抽象缓冲区。抽象数据缓冲区仅在实际数据变得可用时才分配内存。释放内存也变成了抽象数据缓冲的责任。考虑到所有这些，集中内存管理和数据复制操作就会带来以下优点：

各方都能通过调用预定义的 API 函数来构造和/或销毁数据缓冲区。 内存使用将保持接近最优状态，因为缓冲区内存仅在必要时才分配，并且会尽快释放，从而最小化内存泄露。 任何一方都不需要知道底层的内存管理方案，使得软件高度可移植，同时保证了交互双方之间的兼容性。 由于没有哪一方需要管理内存，确定缓冲区的大小就变得不必要了（因而也不可能存在前面指出的多次执行问题）。 事实证明缓冲区溢出也不可能会发生，因为仅当存在额外数据空间时才会复制数据。