变长字符串的内存管理

lenovo

下面的文字是我在看一本书的时候，感觉这部分描述的不错，
所以就把它译了过来，希望能对大家有帮助。
英语不太好，所以有些地方可能会翻译的不好，大家体谅。

写一个C函数，它从一个I/O设备读取一个字符串，然后返回给调用者。字符串的长度不受限制而且不能事先取得它的长度。

这个问题表述了一个常见的编程问题，也就是，在事先不知道一个值的总长度时怎么去读取这个变长的值。这里有几个方法来解决这个问题，
它们的每一个都有自己的权衡。

方法1：静态内存

这里有一个方法来实现帮助函数：

1. 
   
2. const char *
   
3. get_string()
   
4. {
   
5.         static char buf[10000]; /* Big enough */
   
6.         /* Read string inot buf... */
   
7.         return buf;
   
8. }
   

复制代码

这个方法的好处是比较简单,但是它也有很多严重的缺点。

返回的字符串可能比你期望的要长。无论你指定buf什么样的长度，它仍然可能太小。如果实际的字符串太长，你或者超出数组的范围最终导致代码悲惨的失败，或者必须擅自截断那个字符串。

对于较短的字符串，这个函数因为buf数组的大部分没有用到而浪费了内存。每一次get_string调用覆盖了前一次调用的结果。如果调用者想保留前一次调用的字符串，在再一次调用这个函数之前，他必须把上一次的字符串做一份拷贝。

这个函数不是可重入的。如果多个线程同时调用get_string，一个线程会覆盖另一个线程的结果。

方法2：静态指针指向的动态内存

这是第二种实现get_string函数的方法：

1. 
   
2. const char *
   
3. get_string()
   
4. {
   
5.         static char * result = 0;
   
6.         static size_t rsize = 0;
   
7.         static const size_t size_of_block = 512;
   
8.         size_t rlen;
   
9.         rlen = 0;
   
10.         while (data_remains_to_be_read() ) {
    
11.                 /* read a block of data... */
    
12.                 if ( rsize - rlen < size_of_block ) {
    
13.                         rsize += size_of_block;
    
14.                         result = realloc(result, rsize);
    
15.                 }
    
16.                 /* append block of data to result... */
    
17.                 rlen += size_of_block;
    
18.         }
    
19.         return result;
    
20. }
    

复制代码

这个方法使用指向动态内存的一个静态指针，不断地增长缓冲区用来容纳数据。使用动态内存除去了字符串任意长度的限制，当然另一方面它
仍然有前一个方法的问题：每一次调用仍然覆盖前一次调用的结果，函数不是可重入的。这个版本也浪费了相当大数量的内存，因为它永远消
耗最坏情况下的内存数量（它曾经读取的最长字符串的长度）。

方法3：调用者分配的内存

在这个方法中，我们让调用者负责提供容纳字符串的内存。

1. 
   
2. size_t
   
3. get_string(char * result, size_t rsize)
   
4. {
   
5.         /* read at most rsize bytes into result... */
   
6.         return number_of_bytes_read;
   
7. }
   

复制代码

这个就是被UNIX操作系统的read系统调用所采纳的方法。它解决了大部分的问题。包括它是可重入的，不会内存溢出，不会擅自的截断数据。
（潜在的浪费内存的数量在调用者的控制之下。）

弊端在于如果字符串比提供的缓冲区更长，调用者必需保持调用直到所有的数据被读取。（如果我们假定数据源隐含在调用的线程中，那么多
个线程的重复调用是可重入的。）

方法4：返回指针指向的动态内存

在这个方法中，get_string动态的分配一个足够大的缓冲区来容纳结果，并返回一个指向缓冲区的指针。

1. 
   
2. char *
   
3. get_string()
   
4. {
   
5.         char * result = 0;
   
6.         size_t rsize = 0;
   
7.         static const size_t size_of_block = 512;
   
8.         while (data_remains_to_be_read) {
   
9.                 /* read a block of data... */
   
10.                 rsize += size_of_block;
    
11.                 result = realloc(result, rsize);
    
12.                 /* append block of data to result... */
    
13.         }
    
14.         return result;
    
15. }
    

复制代码

这个几乎和第二个方法一样（它们之间的区别是get_string没有使用静态数据）。它几乎解决了所有的问题：函数是可重入的，对于结果字符
串没有一个隐含的大小限制。对于长字符串并不要求多次的函数调用（但是动态分配增加了一些开销）。

这个方法的主要缺点是它让调用者负责释放分配的内存：

1. 
   
2. /* ... */
   
3. {
   
4.         char * result;
   
5.         result = get_string();
   
6.         /* Use result... */
   
7.         free(result);
   
8. 
   
9.         /* ... */
   
10.         result = get_string();
    
11.         /* ... */
    
12. }        /* Bad news, forgot to deallocate last result! */
    

复制代码

在这里，调用者从一个块中返回并没有释放由get_string返回的字符串。被result占用的内存从不会被收回。这种类型的重复错误注定会不可
避免的摧毁调用者。最终，调用者内存溢出并被操作系统终止运行，或者，在一个嵌入式系统，调用者可能会锁定机器。

Alligator27

方法3和方法4稍加改动就可避免以上弊端.

对方法3, 通常的作法是调用者先传入空内存. 函数返回所需内存大小. 调用者再安需分配内存, 然后二次调用函数.

1. 
   
2. size_t BufferSz=0;
   
3. get_string(NULL, &BufferSz);
   
4. char* Buffer = new char[BufferSz];
   
5. size_t BytesRead = get_string(Buffer, BufferSz);
   

复制代码

方法4中, 调用者处理完缓冲区的字符串后应当再调用释放函数release_string(char*). 这样 (a) 资源的分配与释放匹配 (b) 保持各组件的独立. 函数可有多种内存分配方法, 动态分配, 静态内存, 缓存等. 调用者释放字符串后, 函数可保留这个内存, 当有多个调用时可作为缓存来提高速度.

lenovo

原帖由 Alligator27 于 2006-7-4 22:21 发表
方法3和方法4稍加改动就可避免以上弊端.

对方法3, 通常的作法是调用者先传入空内存. 函数返回所需内存大小. 调用者再安需分配内存, 然后二次调用函数.
[code]
size_t BufferSz=0;
get_string(NULL, &Bu ...

请教一下，对你说的方法3还不是很明白。
第一次调用时get_string是怎么获得它需要的空间大小的，
比如read函数。

Alligator27

原帖由 lenovo 于 2006-7-5 09:22 发表

请教一下，对你说的方法3还不是很明白。
第一次调用时get_string是怎么获得它需要的空间大小的，
比如read函数。

我说的是调用者与被调用函数的责任划分. 调用者应当不知道底层的细节. 比如read, 函数本身也许需要分配一块内存, 多次I/O, 再把结果传给调用者. 不管它怎么实现, 目的是减轻调用者的负担.

kuaizaifeng

在一本书看看过类似的讨论，好像最后倾向的是动态分配内存

lenovo

原帖由 Alligator27 于 2006-7-5 09:42 发表

我说的是调用者与被调用函数的责任划分. 调用者应当不知道底层的细节. 比如read, 函数本身也许需要分配一块内存, 多次I/O, 再把结果传给调用者. 不管它怎么实现, 目的是减轻调用者的负担.

我明白了，不过这样会影响效率，
所以read没有这样做，
对吧？

Alligator27

原帖由 lenovo 于 2006-7-5 15:42 发表

我明白了，不过这样会影响效率，
所以read没有这样做，
对吧？

我觉得效率是一个方面. 软件的框架也许是考虑的因素.
具体地说, read是很底层的IO函数. 它的主要目的是隐蔽更底层的硬件, 比如disk, tty, network, pipe等. 效率与逻辑交给上一层, 比如fread.
而get_string()的例子应当是架构上更上一层. 它清楚要读的内容, 从而决定用哪种内存分配. 对不变的东西, 比如configuration, locale, cpuid等, 完全可以用静态内存. 对不能确定长度的stream, 也许只有选择方法3. 对多次重复, 并有众多消费者的情况, 缓存显然是有用的.

mik

说得虚

fl3w

方法3需要在read完所有的数据以前read内部的那个对象一直保持着缓存直到read完，这个句法上感觉不好。（如果是某个类的 .read(),.close()方法就自然得多，可惜这里是c）
方法4感觉调用者职责不清，不太喜欢.

disheng727

原来牛人看的都是英文版的资料，强！